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ABSTRACT 


This thesis documents the development of an interim Small Autonomous 
Underwater Vehicle (AUV) Navigation System (SANS), a self-contained, externally 
mountable navigation package. The purpose of SANS is to determine the position of a 
submerged object of interest located by an AUV. The volume of SANS must not 
exceed 120 cubic inches and total system accuracy of 10.0 meters rms or better is 
required. An Inertial Navigation System (INS) is implemented to compute the ascent 
path during transit from an object of interest to the surface. INS hardware components 
include miniature spin gyroscopes, a compass and a depth transducer interfaced 
through an analog to digital converter. Global Positioning System (GPS) is used to 
determine the AUV’s location after reaching the surface. The reciprocal of the ascent 
vector is applied to the AUV’s GPS position to accurately determine the location of 
the target of interest. A primarily object-oriented software architecture is implemented 
here with extensive software testing to verify the proper operation of key modules. 

The objective of this thesis is to quantify the adequacy of the selected components 
in meeting these requirements and to develop a breadboard design demonstrating the 
basic functions of the interim SANS. This research concludes that the components 
selected for the interim SANS meet the accuracy requirements provided the AUV 
maintains a climb angle which is equal to or steeper than 12 degrees from a typical 
mi.ssion depth of 20 meters. 
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I. INTRODUCTION 


A. BACKGROUND 

Many of the missions proposed for Autonomous Underwater Vehicles (AUV’s) 
require a high degree accuracy in navigation. The Global Positioning System (GPS) 
provides perhaps the most accurate navigation information currently available. The 
feasibility of incorporating GPS into a Small AUV Navigation System (SANS) was 
evaluated by the thesis of James Bernard McKeon with a favorable assessment. Some 
major concerns addressed by McKeon were accuracy, acquisition time (to limit the 
probability of counter-detection) and power consumption. [Ref. 1] 

B. PURPOSE 

There are two distinct phases embodied in the eventual employment of a SANS. 
The first of these is the transit phase involving navigation of the AUV from a launch 
position to an area where an underwater mapping mission is to be conducted. After 
the mapping mission is complete, the AUV will transit back to a recovery position. 
This mission may involve waypoint steering and artificial intelligence applications 
such as obstacle avoidance. The second distinct phase called the mission phase 
involves execution of the mapping mission. The objective here is to determine the 
locations of underwater objects identified by the AUV in the area of interest. 

The purpose of this thesis is to document the development of an interim system 
meeting the mission execution (mapping phase) objectives of the SANS. Specifically, 
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this interim system will occupy less than 120 cubic inches and will demonstrate the 
feasibility ol'determining the position ol a submerged object located by an AUV to 
within 10 meters. The term AUV should include any small underwater vehicle which 
could easily carry such a compact device. 

C. PRINCIPLES OF OPERATION 

The interim system seeks to incorporate GPS position fixing into the SANS. In 
order to resolve the location of a submerged object, two problems must be solved. 
First, the path travelled from the submerged object to the surface must be determined 
since GPS signals cannot penetrate water. Secondly, the AUV's position on the 
surface must be accurately determined so that the location of a submerged object may 
be resolved by applying the reciprocal of the ascent path. 

Commercially available inertial navigation systems will soon exist which exceed 
the accuracy requirements and are compatible with the volume requirements of SANS. 
This would permit identification of multiple targets with only occasional GPS updates 
for navigation accuracy. This capability will be explored in future research. In the 
interim SANS, a pop-up mode is employed in order to locate each underwater object. 
The AUV’s ascent path is calculated trigonometrically by measuring the depth change, 
pitch angle and compass heading throughout the ascent. On the surface, data from the 
GPS receiver is recorded to resolve the location of the target through post-processing. 
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D. SCOPE OF THESIS 


This thesis reports the findings of the second year of research in an ongoing 
research project. The objectives of this thesis are limited to defining the hardware and 
software architecture required to conduct the mapping phase of the mission. These 
objectives are described by McGhee et al. and include [Ref. 2] : 

a. Lx)w Power Consumption. Operation from an external battery pack for 24 
hours is desirable. 

b. GPS antenna exposure time in survey area shoulc. be minimized. Up to 30 
seconds exposure allowed but intervals between sucn exposures should be as 
long as possible, exceeding several minutes at a minimum. 

c. The GPS antenna should present a very small cross section when exposed 
and should not extend more than a few inches above the surface. 

d. For the mapping phase of the mission, system positioning accuracy of 10 
meters rms or better is required with post-processing, submerged as well as 
surfaced. 

e. Total volume not to exceed 120 inches. Elongated, streamlined packaging is 
preferred. 

The feasibility of meeting the objectives of the mapping phase is demonstrated 
initially by a "brealboard" system design. The performance of individual components 
is assessed through analysis of data collected from the "breadboard" system operating 
onboard an instrumented golf-cart traversing a surveyed test track. Eventually, a "wet 
design" prototype is planned which will be carried externally aboard the Naval 
Postgraduate School AUV-2 as part of a technology demonstration. The transit and 
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return phases characterized by more relaxed navigation accuracy requirements will be 
addressed in future research. 

E. THESIS ORGANIZATION 

This thesis explores hardware components required to implement the interim SANS 
and the software architecture to support this mission execution. While the technical 
expertise of the author lies more in the realm of the software design, both topics are 
covered in sufficient detail to ensure that the overall system performance satisfies the 
design objectives. 

Chapter II reviews previous and ongoing work, especially that which relates to the 
incorporation of GPS and inertial navigation into AUV navigation. 

In Chapter III, a detailed problem statement is presented. The requirements for the 
GPS serial line interface and translation of the binary format is examined. Problems 
related to the computation of the distance travelled from datum are di.scussed. 

Possible solutions involving gyros or accelerometers to determine the climb angle are 
examined. 

Chapter IV details the design of the SANS. Those characteristics of the individual 
hardware components which are significant to the design of the SANS are presented. 
The .software design methodology and philosophy is presented in this chapter. 

Chapter V delineates the process and results of software testing. Various 
approaches to testing are considered and a testing philosophy and strategy a’-e 
developed. Reliability of key modules are examined. 
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In Chapter VI. the experimental data gathered during system validation is presented 
along with detailed analysis. The accuracy and adequacy ol' individual components is 
described with comparison to advertised technical specilications. The performance of 
the complete system is also assessed. 

Chapter VII concludes with a summary of the results of this research. Future 
research topics are al.so described. 
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II. SURVEY OF PREVIOUS WORK 

A. AUV NAVIGATION 

A.S staled by McKeon (ref. 1]: 

Approaches to navigating of AUV’s fall into two different categories: sensor 
based navigation and external signal based navigation. Sensor based navigation 
refers to an AUV navigational system that is self contained. 

For AUV missions of extended duration (in excess of 100 hours), current sensor 

based navigation systems alone are considered incapable of providing the accuracy 

necessary to perform precise mapping operations. Most external signal navigation 

systems require continuous exposure of some sort of signal receiver. This is a serious 

restriction which negates many of the advantages of an AUV. McKeon proposes a 

navigation system combining the strengths of sensor based and external signal based 

navigation systems for AUV navigation. (Ref. 1] 

Previously, the most widely available forms of external signal navigation systems 

were Loran and Omega. Both of these are considered unsuitable for AUV navigation 

due to limited coverage, relative inaccuracy and the requirement for uninterrupted 

signal reception in Loran. 

B. INCORPORATION OF GPS INTO AN AUV 

With the Initial Operational Capability (IOC) of the GPS satellite network in 1993, 
continuous worldwide GPS coverage will be available [Ref. 3]. This combined with 
the accuracy of GPS shown in Table 2.1 makes it an ideal candidate for use as an 
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TABLE 2.1 : GPS POSITIONING ACCURACY 
(IN METERS) 



PPS 

SPS 

NON-DIFFERENTIAL 

16 

100 

DIFFERENTIAL 

2-4 

2-4 


external signal navigation source in AUV’s. McKeon provides a detailed analysis of 
the expected accuracy of an AUV based GPS receiver with consideration for the 
requirement to minimize antenna exposure. A navigation solution was achieved in 30 
seconds or less with a 57% success rale (86 of 150 cases). The position errors fell 
within the expected range with a standard deviation of horizontal error of 29 meters. 
[Ref. 1] 

Dr. SeHung Kwak developed an assembly language serial line interface for a GPS 
receiver during implementation of a Suitcase Navigation Data Logger (SNDL) [Ref. 

4], TTiis interface is u.sed extensively in the implementation of the GPS and AUV 
communications here because of its compatibility with Ada, the development language 
for SANS. 

C. INERTIAL NAVIGATION IN AUV’S 

In Reference 2, McGhee et al. examine the incorporation of available inertial 
navigation systems into an AUV. These systems include fiber optic gyros, ring laser 
gyros and vibratory rate sensors. Analy.sis shows that systems exceeding the accuracy 
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requirements within the size and power consumption restrictions outlined in Chapter 1 
are feasible and should be available in 1994. These findings arc supported by the 
work of Hutchinson et al. in Reference 5. 

The utilization of GPS to correct inertial measurements for navigation of an AUV 
is addressed by Brown [Ref. 6] and Nagengast [Ref. 7). A model based on a medium 
grade INS using ring laser gyro’s (RLG’s) and combinations of high and low accuracy 
GPS was used to simulate actual conditions. The results from computer simulations 
matched expectations with one nautical mile per hour drift In the INS. Nagengast’s 
estimate of GPS error is 43 meters (one standard deviation of horizontal error). This 
is larger than McKeon’s result but stiii within the expected range. 

In Reference 8, Miller develops an extended Kalman filter adapted for an AUV 
which seeks to optimize the INS navigation solution. 

D. KALMAN FILTERING TECHNIQUES 

A major objective in the incorporation of GPS into an AUV, especially in a tactical 
environment, is the requirement to minimize the probability of detection. The SANS 
must optimize the accuracy of the GPS position while minimizing the duration of 
antenna exposure. No previous work has been identified which addresses the 
incorporation of a Kalman filtering technique to update a navigation solution for an 
AUV using GPS data. This is due to the narrow scope of the problem in AUV 
navigation where antenna exposure must be minimized and time between exposures 
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may be large. Most commercial GPS receivers already incorporate some filtering 
technique internally to produce position fixes. 
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III. DETAILED PROBLEM STATEMENT 

A. GPS NAVIGATION 

"The GPS has two levels of accuracy, the Standard Positioning Service (SPS), and 
the Precise Positioning Service (PPS)." (Ref. 3] In SPS, an intentional inaccuracy is 
introduced into the satellite broadcast signals to degrade the accuracy of non-PPS 
receivers through a process called Selective Availability (SA). This limits the 
accuracy of the GPS solution of non-PPS receivers in real-time to 100 meters (two 
standard deviations horizontal error) unless differential processing is used. PPS 
proce.ssing requires the use of cryptographic keys to decode and remove the error in 
broadcast signals and yields an accuracy of 16 meters as shown in Table 2.1. [Ref. 10] 

The use of cryptographic keys aboard an AUV is undesirable. Even with relatively 
tamper-proof secure devices, the potential for loss causes concern. As seen in Table 
2.1, real-time differential processing or differential post-processing can improve GPS 
accuracy to 2-4 meters (SA on or off) negating any advantage of proce.ssing with SA 
off. This also alleviates the concern of placing cryptographic keys aboard an 
unmanned vehicle. 

A commercial GPS receiver man ‘factured by Motorola is being used to conduct 
research in the development of the interim SANS system. In order to achieve the 
objectives for accuracy during the mapping phase established in Section I.D.d, 
differential processing is required. To permit differential post-processing, the GPS 


10 





receiver transmits satellite range format messages containing "raw" (unprocessed) 
satellite range data. These messages are transmitted through a serial connection to the 
host computer where they are stored in non-volatile memory. A second receiver 
operating concurrently at a known location is used to determine and record the total 
error degrading GPS accuracy. This error includes inaccuracy due to atmospheric 
conditions and SA. The error in the range data recorded by the SANS is corrected 
during post-processing to yield the accuracy described in Table 2.1. 

Position format messages, which are another message format transmitted by the 
GPS receiver, permit navigation updates during mission execution or during transit. 
Both position format and satellite range format messages are transmitted in Motorola 
proprietary binary format in RS-232 compatible serial stream. In position format 
mc.s.sages, the latitude and longitude are .32-bit two’s complement encoded in 4 bytes 
each. This binary format necessitates the development of a module capable of 
receiving, storing, and processing variable length binary data streams. 

In order to conserve power, the GPS receiver must be unpowered when not in 
operation. Since this receiver cannot output position and satellite range format 
messages at the same time, initialization must provide for transmission of the 
appropriate message format depending on the current mission phase. During transit 
phase, the receiver must be initialized to transmit position format messages for 
position updates. During mapping phase, satellite range format message transmission 
must be initialized to provide satellite range data for post-processing. 
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B. SUBMERGED NAVIGATION 

In order to calculate the distance from a submerged object to the surface where an 
accurate GPS fix can be obtained, the depth change, climb angle and direction of 
travel (heading) must be known. Heading is measured by a compass and depth change 
is measured by a depth transducer. The compass and depth transducer selected for use 
in SANS both produce an analog output which is converted to digital data by an 
Analog to Digital (A to D) converter. The specifications and interface for these are 
covered in the section IV.A (system hardware) and Appendix A (technical 
specifications). 

Figure 3.1 and equation 3.1 illustrate the trigonometry involved in computation of 
horizontal distance. Figure 3.2 and equations 3.2 and 3.3 illustrate how heading and 
horizontal distance travelled are resolved into latitude and longitude components. 
Rather than computing a single vector travelled at the surface, SANS sums a series of 
vectors calculated for small increments of time during the ascent. This should improve 
accuracy due to frequent heading and climb angle changes through the ascent. A 
differential error analysis is conducted using this approach in section VI.D.2. In 
computing the horizontal distance travelled in equation 3.1, as the climb angle 
approaches zero, the horizontal distance travelled will approach infinity (the AUV will 
never reach the surface since the climb angle is zero). Therefore, the minimum climb 
angle consistent with system accuracy objectives for the interim SANS system must be 
quantified. 
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Figure 3.1 : Computation of Horizontal Distance Travelled 



LATITUDE 

CHANCE 


Figure 3.2 : Computation of Latitude/Longitude Change 
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(3.1) 


DEPTHCHANGE 

TAm 


6^=s^*COSa 


(3.2) 


6X=Sfj*SINa 


(33) 


Where © is Ihe climb angle. 

0 is the latitude 
lambda is the longitude 

The measurement of the climb angle pre.sents the greatest challenge within the 
space requirements of the SANS. Two approaches are developed here using a 
miniature gyroscope (gyro) and a single axis accelerometer. 

1. Gyroscope 

A miniature spin gyro manufactured by Gyration Inc. is small enough for use in 
SANS and has a very low power requirement (0.1 watts). While the drift rate of the 
gyro is high, it should be acceptable for the short period of time required to travel 
from a submerged object to the surface. The error rate of the gyro is evaluated and 
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impact on system accuracy are assessed in section VI.D along with other system 
hardware. 

The gyro’s rotational positional information is encoded in two phase and 
quadrature digital data signals as illustrated in Figure 3.3. These signals encode the 
output of an optical encoder. The direction of gyro rotation can be determined by 
observing which signal rises first and the amount of rotation can be determined by 
counting the number of pulses. One period of rotation in the optical encoder begins at 
the rising edge of a pulse in either output signal. The period includes both pulses in 
the pulse pair and ends at the beginning of the next rising edge in either output signal. 
One period represents 0.8 degrees of rotation in a low-resolution gyro (0.4 degrees in 
high-rcsoluiion). Only relative position is available from the gyro. The solution in 
SANS assumes a near level attitude for the AUV at the time an object of interest is 
located on the bottom. Climb angles during the ascent are relative to this assumed 
horizontal attitude. 

The manufacturer provides a development test box which converts this output 
into a serial data stream. This test box is too bulky for inclusion in SANS so use of 
gyro information necessitates development of a module to track gyro rotation. This 
rotation can be applied to the last known climb angle at regular intervals during the 
ascent to determine the gyro’s new relative position. 

A significant problem encountered by Gyration Inc. is high frequency noise in 
the output signal while the gyro is stationary as shown in Figure 3.4. This noise is 
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SIGNAL A 



SIGNAL B 






^ONE PERIOD OF _*j 
OPTICAL ENCODER^ 



*NOTE : Overlapping pulses indicates valid gyro rotation 


Figure 3 J : Phase and Quadrature Signal Output 


SIGNAL A 


SIGNAL B 


Note ; Non-overlapping pulses indicate presence of noise only 
(no valid gyro rotation is present) 


Figure 3.4 : Noise in Phase and Quadrature Signal Output 
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random and can occur in one or both channels. The software solution developed to 
track gyro movement must filter out this noise. This can be accomplished by taking 
advantage of the fact that signals describing valid lotation must follow certain state 
transition patterns. These patterns will be used in the next chapter to develop a state 
transition algorithm to count valid slate transitions while rejecting invalid slate 
transitions as noise. The pulse count can then be incremented or decremented by the 
algorithm accordingly. 

2. Accelerometer 

A second approach which may be developed to determine climb angle in the 
SANS is inertial measurement based on an accelerometer. McGhee develops a finite 
approximation of climb angle using the output of a single-axis accelerometer. This is 
accomplished by sensing the component of gravity along the axis measured by the 
accelerometer. The longitudinal acceleration of the AUV is assumed to be negligible 
(constant velocity). This allows the x-axis (vertical) acceleration to be used to 
determine the climb angle. (Ref. 9j 

McGhee points out that a measurement of rotation based on accelerometers will 
yield best resulLs during low frequency rotation since the precession error in the gyro 
is predominant. The reverse is true during high frequency pitch altitude excursions 
where gyros are preferred since the effect of precession error is minimized. A hybrid 
solution using both accelerometers and gyros would optimize the strengths of each 
approach. [Ref. 9] 
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Similar logic applies in measuring heading change. The compass is preferred 
undf'r stable conditions due to the predominance of precession error in the gyro. 

During a high rate of rotation, howeve., the directional gyro yields a better result since 
the effect of precession error is minimized. Again, a hybrid solution using the gyro to 
smooth compass heading changes during turns is preferred. 
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IV. SYSTEM DESIGN 


A. HARDWARE DESCRIPTION 

A brief description of each hardware device is provided here to summarize some of 
the significant characteristics essential to the design of the interim SANS. Appendix 
A provides a more detailed summary of each device’s technical specifications. Figure 
4.1 illustrates the hardware interface. 



Figure 4.1 : SANS Hardware Devices Interface 
1. Sapphire Converter 

The Diamond Systems Sapphire card provides a variety of features. The key 
features utilized in the development of SANS are the Analog to Digital (A to D) 
conversion and the Digital to Digital (D to D) Input/Output (I/O) capability. 
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The Sapphire D to D interface provides a 7-bit digital I/O port through a DB-37 
connector (37-pin). These include 3 input and 4 output pins. The DB-37 also 
provides a single external trigger input channel. A 24-bit general purpose I/O port is 
also provided through the 82C55 programmable interface. Each group of 12 pins may 
be programmed in sets of 4 pins and 8 pins as inputs or outputs. This permits 
definition of three 8-bit ports (A through C). Port C can be divided into 2 4-bit ports 
under mode control. Each of these 4-bit ports can be combined with an 8-bit port to 
provide 12-bit input/output if desired. 

The analog interface provides 8 analog input channels through the software 
controlled input channel multiplexer. While there are 3 selectable voltage ranges (+/- 
5 volts, 0-10 volts and +/- 10 volts), the multiplexer can actually tolerate voltages of 
up to +/- 32 volts. 8-bil output resolution (1 part in 256) or 12-bit output resolution (1 
part in 4096) with a 20 micro-second A to D conversion lime is software selectable 
for each analog input channel. [Ref. 10] 

One serious limitation imposed by the Sapphire converter is the availibilty of 
only a single interrupt input channel. This restricts the current software architecture to 
tracking a single gyro at any given time. The interface chosen for the target machine 
should have at least two interrupt channels so that the directional gyro may be used to 
aid in heading updates. This is especially important during high rates of turn as 
discussed in Section III.B.2. 
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2. Core Module 


The Dover Electronics ESP 8680 (Extra Small Package) core module provides 
an 8086 equivalent central processor. One megabyte Dynamic Random Access 
Memory (DRAM) is provided as well as two serial ports (RS-232). This module was 
chosen for its compactness (1.7 inches by 5.2 inches by 1/3 inch) and for its power 
conservation features. Several modes of operation are provided including full speed 
operation at 14 megahertz and a low power consumption "drowsy mode" operating at 
1 megahertz. Typical power consumption is 0.2 watts at 8 megahertz [Ref. 11]. Two 
megabyte EPROM (Eraseable Programmable Read-Only Memory) non-volatile 
memory modules are currently available. 20 megabyte memory modules are expected 
to be available shortly. Additionally, the manufacturer is currently developing a 
miniaturized A to D converter with capabilities equivalent to the Sapphire A to D 
converter. 

3. GPS Receiver 

The Motorola PVT6 is a lightweight miniature GPS receiver capable of tracking 
six satellites simultaneously. The receiver is capable of real-time differential 
processing and can be upgraded to support PPS. Acquisition time is 24 seconds 
typical time to first fix with an accuracy of 100 meters with SA on without differential 
proce.ssing. With differential processing, 1 - 5 meters accuracy is probable. 

When power is applied, the receiver is initialized in the mode that existed when 
power was last removed. The most recent valid coordinates are stored by the receiver 
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through reinitialization. This is accomplished by transmitting a formatted binary 
command (message) through the serial communication line. 

Serial stream output is provided through an RS-232 standard interface in a 
variety of formats. These include National Marine Electronics Association (NMEA) 
standard format. Motorola Proprietary Binary format and LORAN input/output format. 
Although the NMEA standard format would be very attractive from the standpoint of 
compatibility between various receivers, the Motorola Proprietary Binary format was 
selected since it provides both satellite range information for differential post¬ 
processing and position formal messages (although not concurrently). 

4. Gyroscopes 

The Gyration GyroEngine is an optically sensed miniature spin gyroscope 
(gyro). There are two varieties of gyro available from Gyration, vertical and 
directional. Both are used in this interim system. The vertical gyro inner gimbals 
encoder measures the pitch attitude of the AUV during ascent from the object of 
interest. Roll attitude measured by the outer gimbals is not of interest in this system. 
The directional gyro’s outer gimbals reports yaw information and may be used to 
smooth the compass heading data during high turn rates. 

The GyroEngine generates two phase and quadrature digital data signals from 
each gimbals encoder. A test box provided by Gyration, Inc. translates this signal into 
serial stream data interfaced through an RS-232 serial port connection. The test box is 
useful for evaluating the performance characteristics of the GyroEngine, but is too 
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bulky to be used in the SANS. A software solution has been developed to permit the 
GyroEngine to interface directly with the ESP-8680 through Sapphire A to D via 
Digital Input/Output (DIO). This solution is developed in Section IV.B.2.f and 
Appendi.x D. 

5. Compass 

The KVH Cl00 Multi-Purpose Digital Compass provides digital output in a 4 
digit Binary Coded Decimal (BCD) serial stream format. Analog output is provided in 
the form of linear or sine/cosine voltage signal. Since the serial stream digital output 
would require an additional serial port connection in the ESP-8680, the compass 
analog output is interfaced through the Sapphire A to D converter. A linear voltage is 
produced proportional to heading in the range from 0.1 volts (000 degrees) through 1.9 
volts (360 degrees). This voltage is converted to digital data by software triggered A 
to D conversion mode through the Sapphire A to D converter. The analog signal from 
the compass is connected to the Sapphire through one of 8 multiplexed input channels. 
This input channel is selectable in the parameters file A_TO_D.DAT at run-time. 

6. Depth Transducer 

The Omega Inc. PX176-100S5V Depth Transducer has an operating range of 0 
to 100 pounds per square inch static pressure (PSIS). This equates to 6.7 standard 
atmospheres or 217 feet (67 meters) Jep-.h of sea water. Analog output is 1 to 6 volts 
direct current (DC). A to D conversion is performed by repetitive software triggered 
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single A lo D conversions in the same manner as the compass signal with the analog 
input channel similarly selectable. 

B. SOFTWARE ARCHITECTURE 

The software design for the SANS, can be described at the highest level by three 
major operations. These are; 

- Monitoring the AUV for a position fix request, 

- Navigation data-logging for dead reckoning (DR) navigation (post-processed to 
determine ascent vector), and 

- GPS data-logging for post-processed positional information. 

AUV monitoring must be performed continuously in the event of a request by the 
AUV to determine the location of a submerged object of interest. This permits the 
GPS to be unpowered while the AUV is submerged and is intended as an energy 
conservation measure. DR navigation in the interim system consists of measuring the 
horizontal distance travelled from a submerged object to the surface as described in 
Figures 3.1 and 3.2. After the AUV reaches the surface, the GPS position is provided 
through a serial port connection from the Motorola GPS receiver. 

The programming language used in the development of SANS is Meridian Ada 
version 4.].]. Assembly language is used for low level, high frequency operations to 
improve efficiency. The object code for these assembly language modules are 
compiled by Borland’s Turbo-Assembler and linked with the Ada object code using 
Borland’s Turbo-Linker. 
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In order to produce a logical structure, a precise definition of design 
requirements is essential. "The primary product of this phase is an approved 
development (functional) software specification." as stated by Booch [Ref 11]. These 
requirements form the basis for development of the software structure. They also 
permit formulation of a test plan to evaluate the performance of the overall system and 
of individual modules. 

a. A UV Monitoring. 

AUV monitoring shall be performed continuously during the mapping phase 
so that when an object of interest has been located by the AUV, sufficient data may be 
recorded to determine the geographic position of the object. Communication with the 
AUV shall be via RS-232 serial line communication. DR navigation and GPS 
processing shall remain inactive with GPS unpowered (except for a low voltage 
applied to preserve static RAM (SRAM volatile memory) until the AUV requests a 
position fix. 
h. GPS. 

The GPS shall be initialized with the receiver in the Motorola proprietary 
binary format when the AUV requests a position fix. The receiver shall be 
programmed to transmit both position/status and satellite range format messages on a 
one second interval when initialized. The host computer shall be configured to receive 
RS-232 serial communications with connection parameters specified from an input 
data file at run-time. Upon mission termination, the host machine configuration shall 
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data file at run-time. Upon mission termination, the host machine configuration shall 
be restored to the state which existed prior to SANS execution. This is primarily to 
prevent side-effects due to improper configuration in the software development 
machine during software development. 

All information received through the serial connection by the host machine 
shall be written to non-volatile memory prior to real-time processing. Satellite range 
messages will be recorded for post-processing only, while position/status information 
may be processed for navigation updates as necessary. Position format messages shall 
be processed to determine the current position and PDOP for navigation upniates and 
the checksum to validate the particular message. 
c. DR Navigation 

DR navigation outputs shall include pitch attitude and heading in degrees 
and depth in meters. DR processing shall record input values with a precision 
commensurate with component accuracy and sufficient to satisfy system accuracy 
requirements specified in section I.D.d. 

(1) Pitch Angle. Gyro position shall be monitored continuously by a process 
transparent to SANS operation. The process shall take a pair of standard phase and 
quadrature signals as inputs. Valid pulse pairs [Fig. 3.3] shall be counted on a 
continuous basis with each unit representing +/- 0.4 degrees of rotation depending on 
the direction of rotation. Invalid pulses from either signal [Fig. 3.4] are considered 
"noise" and shall be disregarded in the pulse count. The cumulative value of the pulse 
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count shall be continuously available for interrogation by the main procedure for DR 
navigation. 

(2) A to D Conversions. Sapphire A to D conversions shall be initialized 
from a data file containing the multiplexed channels to be used for heading and depth 
inputs. Analog to digital conversion of analog heading and depth output shall provide 
12 bit accuracy (one part in 4096). Digitized output shall be converted into meters for 
depth and degrees for heading. 

2. Software Design 

The object oriented design methodology described by Booch [Ref. 11] is used in 
the design of SANS. The object oriented approach was selected because it provides 
an advantage in the management of complexity of the system at the highest level over 
other design approaches. 

As the system is decomposed hierarchically, some smaller elements are more 
logically approached using a functional design methodology. The functional design 
engineered by Dr. Kwak for the serial line interface was retained in SANS for both 
AUV monitoring and GPS proce.ssing. This approach is also well suited for the 
implementation of the procedure oriented assembly language driver for the gyro. 

Booch suggests the following sequence in the object-oriented design approach 
[Ref. 11]: 

- Identify the objects and their attributes 
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- Identify the operations that affect each object and the operations that each 

object must initiate 

- Establish the visibility of each object in relation to other objects 

- Establish the interface of each object 

- Implement each object 

a. Identify the Objects 

The purpose of DR navigation in the interim system is to produce a \ jctor 
travelled by the AUV from the submerged object to a position on the surface where a 
GPS fix is obtained. Figure 3.1 illustrates the computation of the horizontal distance 
travelled from the pitch angle and depth change during the ascent. Figure 3.2 
describes the calculation of the change in latitude and longitude from the heading and 
horizontal distance travelled. 

In order to accomplish the objectives of DR navigation, the AUV’s heading, 
pitch angle and depth change must be accessed for each update cycle. This is 
accomplished repetitively in small increments throughout the ascent. These data items 
are treated as objects as described in Table 4.1. Every instance of each object type is 
stored in a file for post-processing. During post-processing, these values are used to 
calculate a heading and horizontal distance travelled by the AUV from the target 
located by the AUV to the surface. The reciprocal of this vector can be applied to the 
GPS position on the surface to determine the target’s location. Determination of 
heading in this implementation is restricted to compass only due to the restriction of a 
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TABLE 4.1 : OBJECTS AND OPERATIONS ASSOCIATED WITH SANS 



OBJECT 

OPERATION(s) 

DR Navigation 

Pitch Attitude 

Current Value 


Depth 

Current Value 


Heading 

Current Value 


Delta_Lat_Long 

DELTAUPDATE 

GPS Navigation 

NAV_DATA_TYPE 

PROCESSGPS 


single inicrrupi input channel in the Sapphire Converter. This restricts the ability to 
support a second driver to track rotation of the directional gyro. 

The primary object associated with GPS is the class object 
NAV_DATA_TYPE. This object is generated by an operation PROCESS GPS 
adapted from Dr. Kwak’s functional implementation of a serial line interface in SNDL 
(.sec section II.D) consisting of latitude, longitude, position dilution of precision 
(PDOP) and time. Each position format message is processed to determine the 
position and PDOP to construct an instance of NAV_DATA_TYPE. The lowest level 
of PROCESS_GPS is the message interpreter MOTOROLA which replaces SNDL 
interpreters for other receivers. These receivers produce incompatible GPS message 
formats. Table 4.1 summarizes the objects essential to the operation of SANS at the 
highest level along with their associated operations. 
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b. Identify the Operations 

The only operation associated with the basic elements of DR navigation is 
CURRENT_VAHJE of that object. For heading and depth, this is accomplished 
through module A_TO_D. This module outputs a 12-bit digital value which is 
proportional in the range 0 through 4095 to the analog output of the respective 
instrument. These values are translated into appropriate units and written to non¬ 
volatile memory by CURRENT_HEADING and CURRENT_DEPTH respectively. 
Pitch attitude is tracked by an interrupt-driven service routine which may be queried 
for CURRENT_PITCH at any time by the main procedure. 

c. Establish the Visibility 

MONITOR_AUV interfaces directly with the AUV through a serial line 
interface to determine when an object of interest has been located by the AUV. It has 
no visibility of PROCESS_GPS or DR_NAVIGAT10N but simply relinquishes control 
to them when an update is requested. CURRENT PITCH is invisible to all other 
operations as is PROCESS_GPS. Heading and depth analog to digital conversions 
both use A_TO_D but have independent routines for conversion to appropriate units. 
cL Establish the Interface 

The interface of objects is described fully by the specification of each 
package contained in the source code for SANS in Appendix B. Figure 4.2 illustrates 
the order of module dependency. 
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Figure 4.2 : Module Dependency Diagram 

e. Implement Each Object (Analog Conversions) 

The Sapphire A to D converter accepts control parameters through control 
registers 1 and 2 which are mapped to the I/O address space of the host CPU. The 
I/O address space map is shown in Table 4.2. Control registers 1 and 2 are accessed 
by offsetting the base address (factory preset at 300 Hexadecimal) by 2 and 3 
respectively. Meridian Ada package Port provides procedure OUT BYTE which 
writes a byte to the specified output port and function IN_BYTE which reads a byte 
from the specified input port. 
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TABLE 4.2 : SAPPHIRE I/O ADDRESS SPACE MAP 


Write 

Read 

8-bit A to D Trigger 

4 LSB’s from A to D 

12-bit \ to D Trigger 

8 MSB’s from A to D 

Control Register 1 

Status Register 

Control Register 2 

No Function 

Counter 0 Register 

Counter 0 Registei 

Counter 1 Register 

Counter 1 Register 

Counter 2 Register 

Counter 2 Register 

Counter Control 

Register 

No Function 

Port A Output 

Port A Input 

Port B Output 

Port B Input 

Port C Output 

Port C Input 

DIO Control Register 

No Function 

No Function 

No Function 


Offset From Base 
Address 



8 


9 


10 


11 


12-15 


The sequence of operations in the A to D conversion is [Ref. 10]: 

(1) Control register two is used to program the voltage rap~e to be used (0 - 
10 volts). The three least significant bits (LSB) in control register one select the 
multiplexed channel (0 to 7) matching the desired analog input port being utilized. 

(2) After specification of the channel and voltage level to be used for the 
conversion, a switching time (minimum 8.5 micro-second delay) is programmed to 
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allow the multiplexed channel to stabilize at the analog input level. The conversion is 
then triggered by writing at the base address with an offset + 1 (301 hexadecimal). 

The written data can be any value but an ASCII character 1 is used for this specific 
application. 

(3) After the conversion has been triggered, the conversion status register’s 
most significant bit (MSB) indicates status of the conversion (1 indicates complete). 
This register is located at I/O address 302 hexadecimal (base address + 2). The 
register’s contents are read in a loop using package Port’s function IN_B’YTE until the 
MSB indicates conversion complete. 

(4) The conversion result is read from the two analog output registers using 
IN_BYTE. The 4 MSB’s from the base address provide the conversion result’s 4 
LSB’s (called the LSBS). The byte from base address + one provides the 8 MSB’s 
(called the MSBS). The digital output value is determined by applying equation 4.1. 

(4.1) 

16 

The division by 16 in the LSBS simply removes the 4 LSB’s from the register 
contents. The multiplication by 16 in MSBS shifts this byte 4 bits to the left. 

/ Implement Each Object (Digital Phase Counting) 

Pitch angle is one object used in the computation of horizontal distance 
travelled from the datum as shown in Table 4.1. Digital phase counting of gyro phase 
and quadrature signal outputs is accomplished by initialization of the interrupt service 
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routine. This requires that the interrupt vector table be modified so that the interrupt 
level used to interface the gyro input may be handled by the service routine. The 
.service routine implements the state transition algorithm developed below to track 
valid state transitions. The service routine and algorithm are procedure oriented in 
nature. Therefore, a functional implementation for this object is appropriate. 

Development of the device driver for the gyro was accomplished in three 
m.'ijor phases. Initial development concentrated on determining the characteristics of 
the phase and quadrature output of the gyro through development of a timed polling 
system. The data collected by the polling system was used to develop and test a state 
transition model and algorithm to filter out noise and track gyro rotation through valid 
state transitions. Finally, after development of the state transition algorithm, an 
assembly language interrupt routine was developed with a service routine adapted trom 
the Slate transition model. 

(1) Polled Sampling System. A polled system sampling both outputs of a 
particular gimbals on a 1.0 millisecond interval was developed using the Sapphire 
82C54 programmable interval timer. The phase and quadrature signals are designated 
lines A and B by Gyration’s documentation. {Ref. 13] As illustrated by Figure 3.3, 
clockwise rotation of the gyro is indicated by a phase shift to the right (the level of 
signal A will still be low after signal B has risen). For each pulse, 0.4 degrees of 
rotation (0.8 degrees in low-resolution gyros) has occurred and the event counter is 
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incremented to reflect this. Counter-clockwise rotation is indicated by a phase shift to 
the left (signal A has risen before signal B) and the counter is decremented. 

The phase and quadrature output of the gyro is interfaced through the 
Sapphire card in the Digital I/O (DIO) mode of operation. The inner gimbals output is 
used lor pitch attitude information. Inner Gimbal A (IG-A) is interfaced through IPl 
(pin 25 of the DB'37) and Inner Gimbal B (IG-B) is interfaced through IP2 (pin 26). 

A 1.0 milli-second polling interval (1,000 Hz) represents a rate which 
significantly exceeds the gyro’s highest rate of 10,000 rpm (167 Hz) at 5.0 volts. The 
82C54 (programmable interval timer) in the Sapphire card is used to time the read 
operations. Mode .3 of the 82C54 provides a square wave through any of the .3 
counters in the 82C54. An initial count N is written to the counter control register 
(base offset + 7) and the counter decrements the loaded value N until this value 
reaches zero. When this oceurs, the counter produces one pulse and reloads the 
counter with initial count N. This sequence of operations repeated results in a square 
wave with a period of N clock cycles. Counter 2 is used for this application since it’s 
clock input is connected to the host computer’s I/O bus clock. Therefore, calibration 
of the timer is dependent on the host’s I/O bus clock speed. The 1.0 milli-second 
interval on the host machine with a 8.0 mHz I/O clock is achieved by programming an 
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initial count (N) of 8,000 into the counter control register. This produces a square 
wave with a period of 8000 clock cycles so that the gyro input is polled at a rate of 
1,000 Hz at 8.0 mHz as shown in equation 4.2. 

The current value of the digital inputs are read through the status register 
(Sapphire base offset + 2) with bits 5 and 6 representing quadrature input values at the 
time of the sampling. To extract the values of the 4 MSB’s from the 8-bit input, 
divide by 16 to remove the 4 least significant bits (LSB’s). 


INPUT 

INPUT BITS5-B= -■ 
16 


(43) 


Take the remainder of a division by 4 to extract bits 5 and 6. 


INPUT BITS5-6=REMAINDER- 


INPUT BITS5-8 


(4.4) 


Bit 6 is the result of a division by 2 and bit 5 is the remainder of a division by 2. 


INPUT BIT5=REMAINDER- 


INPUTBITS5-6 


(4.5) 


INPUT BIT6^- 


INPUT BITS5-6 


(4.6) 
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The current phase and quadrature input is read once at the beginning of 
each 1 milli-second counting cycle. After the current phased quadrature inputs are 
recorded, the value in counter 2, which is accessed at I/O address 306 hexadecimal 
(base address + 6), is monitored until the counter cycle ends. Specifically, to read the 
count, the counter must first be "latched". This records the counter value for the read 
operation while allowing the counter to continue lO decrement. To determine when a 
cycle has expired, the counter register value is monitored. When the value in the 
counter data register reaches zero, the counter control register writes back the initial 
count N (8,000). When this rise in the counter register is detected, the cycle has 
expired and 1.0 millisecond has elapsed. At this point, the status register is read to 
determine the current phase and quadrature signal levels and the sequence begins 
again. 

The sequence of operations is the polled state transition counting is: 

(a) Write the initial count (N = 8,000) to the counter control register to 
establish a 1.0 millisecond interval on an 8.0 mHz I/O bus clock. 

(b) Read the status register of the Sapphire board and extract bits 5 and 
6 (equations 7 through 10) to determine the current phased quadrature value of IG-A 
and IG-B. 

(c) Monitor the counter by latching counter 2 and reading the value. 
Repeat this process until the counter is incremented back to the initial count (8,000) 
then return to (a). 


37 





(2) State Transition Model Development. After the characteristics of the 
phase and quadrature output were determined through the timer based polling system, 
a state transition model was developed to track valid pulse pairs while filtering out 
"noise". The state represents the most recent value of the gimbals signals A and B 
where 0 is low (no pulse) and 1 is high. The state transition input similarly represents 
the new value of the gimbals signals and will always result in a transition to the 
corresponding state. The output is dependent on the path travelled in the transition, 1 
for valid state transitions and 0 for invalid transitions. 

If the states of the lines A and B are a and b, then the system state can 
be denoted ab. There are 4 possible states described by all combinations of a and b. 
Because the software senses only transitions of either a or b from 0 to 1, the state 0,0 
is not visible to the software. Therefore, the software is designed around the three- 
stale transition model in Figure 4..'^. Figure 4.4 and Table 4.3 describe the tracking 
algorithm for the reduced slate transition model. 

The interrupt driven approach to digital phase counting results in two 
observable events in one period of the optical encoder’s output. The beginning of a 
period is indicated by a transition to state 1 or state 3 since a pulse has occurred in 
either signal output. If the other output signal produces a pulse while the first signal 
is still high, a transition to state 2 will occur. In this case, the pilch count will be 
incremented or decremented as appropriate. Otherwise, the signal returns to state 1 or 
state 3 and the event is disregarded in the pitch count. Each unit of pitch count in the 
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Figure 4.5 : Interrupt Driven Three-State Transition Model 

procedure 3_state_tracking_algorithm is 

currcnt_statc, lasl_state : state(1..3) 
piich_c()unt : integer := 0 

begin 

loop 

if current_state = 2 then 

if last_state = 1 then (case 3, clockwise rotation) 
increment pitch_count 

elsif last_state = 3 then (case 1, counter-clockwise rotation) 
decrement pitch_count 
end if 

else 

no trackable rotation has occurred (case 0, 2 or 4) 
end if 

last_state := current_state 
get(current_state) 
end loop 

end 3_state_tracking_algorithni 

Figure 4.6 : Three-State Transition Model Tracking Algorithm 
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ihrcc-siate algorithm represents one period of the optical encoder (0.8 degrees of 
rotation in a low-resolution gyro). Verification of the algorithm is contained in 
Chapter V (Software Testing) and Appendix D. 

(3) Interrupt-Driven Solution. The interrupt routine is modelled loosely after 
the serial line service routine developed by Dr. Kwak and used for GPS interface in 
SANS. LPTl (level 7) is used as the interrupt number to interface interrupt inputs. 
The interrupt service routine implements the reduced state transition model which 
compares the current and previous state signals to track gyro rotation. [Ref. 12] 

The interface of IG-A and IG-B (inner gimbals lines A and B 
respectively) is the same as for the polled system with an additional interrupt signal 
input. IG-A and IG-B are sampled immediately after each interrupt. Sapphire 
provides one interrupt input channel and the interrupt service routine requires rising 
edge trigger on either signal (IG-A or IG-B). An integrated circuit was developed by 
Dr. Kwak [Ref. 14] to generate distinct leading edges for interrupt triggers. 

Each gimbals signal is first processed by a dual one-shot (74LS221) 
integrated circuit (1C). This IC generates a 10.0 microsecond pulse on the leading 
edge of the input signal pulse. The two signals are combined through a quad OR IC 
(74LS32) and input through INT.IN (pin 24 of the DB-37). The 10.0 microsecond 
pulse triggers the interrupt service routine. The service routine reads the value of each 
gimbals signals. These values are compared with the previous signal values as 
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illustrated in Figure 4.4 to determine what rotation, if any has occurred. A review of 
the major operations in the interrupt routine are contained in Appendix C. 



INTERRUPT 

INPUT 


Figure 4.5 : Phase and Quadrature Interrupt Input Signal Generation 

The driver developed performs very well as expected with the gyro in 
motion and at rest. The solution appears practical for the short duration, highly 
dynamic operations intended for SANS as verified in chapter VI. 

3. GPS Update 

The Suitcase Navigation Data Logger (SNDL) designed by Dr. Se-Hung Kwak 
establishes the framework for an RS-232 serial port interface to a GPS receiver. This 
design was kept largely intact for the GPS interface. The lowest level packages 
involving the GPS message translation were completely redesigned due to differences 
in receiver message format. The basic design philosophy for GPS processing in 
SNDL remains unchanged in SANS. 

The AUV may request a GPS update during transit phase for a navigation check 
or during the mission execution when an object of interest has been located. As with 
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the gyro driver, the GPS serial line communication is established at each GPS update 
request and is terminated at completion of that update. 
a. Serial Port Communication 

When SANS detects an update request from the AUV, the GPS is powered 
up and INrT_GPS establishes the serial connection with the GPS receiver. The 
parameters for the connection are specified in the file SETUP.DAT. The initialization 
routine establishes a buffer where the interrupt service routine writes the bytes 
received through the connection. 

Motorola proprietary binary message format was chosen for data 
transmission from the receiver. This is the only format which allows transmission of 
both position information for real-time navigation and satellite range information for 
post-processing. 

PROCESS_GPS permits the main procedure to test for a GPS message by 
checking the buffer established during initialization through procedure READ_CHAR. 
The result of this procedure includes a status value which indicates whether the buffer 
has any new data (messages). When data is in the buffer, all data is processed before 
exiting to wait for another message. READ_CHAR is an assembly language program 
linked with the SANS program’s Ada object code through pragma interface. Each 
character read through the serial interface is written to an output file for post¬ 
processing before any real-time processing. 
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b. GPS Message Translation 

There are two message formats transmitted by the Motorola receiver. 
Position format messages are 68 bytes in length and are distinguished by the 4 byte 
header @@Ba. The 122 byte satellite range response message is recognized by the 4 
byte header @@Bg. 

If the first 4 bytes of the message match the position format message, the 
message is processed to produce an instance of NAV_DATA_TYPE. This is a 
composite type (record) consisting of latitude and longitude in degrees, minutes and 
seconds, PDOP and time as described in Section IV.B.2.a. Package Nav provides a 
procedure for translating milli-arcseconds in long-integer into degrees and fractions of 
degrees. 

Bytes 16 through 19 encode a 32 bit two’s complement long-integer. This 
value represents the latitude in milli-arcseconds in the range +/- 324,000,000 (+/- 90 
degrees). Bytes 20 through 23 similarly represent the longitude in the range +/- 
648,000,000 (+/- 180 degrees). 

To convert the 32-bit two’s complement number (4 bytes) to long-integer 
format, the parity must be determined by comparing the first byte with 127. If the 
first byte is greater than or equal to 128 (40 hex), then the first bit is one and the 
value therefore represents a negative number in two’s complement form. In this case, 
all 4 bytes must be converted to a negative equivalent by subtracting 255 from each. 
A boolean flag is set to trigger the subtraction operation on each succeeding byte. 
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Each byte is multiplied by the appropriate factor as shown in equation 4.7 to 
determine the long-integer equivalent. 

L0NG-1NTEGER=BYTE1 -2^*BYTE2*2'^*BYTE3>2*BYTE4 

The value of PDOP, taken from bytes 36 and 37, provides the relative 
quality of the position to aid in integration into the update solution. Byte 66 contains 
a checksum which is the exclusive OR (XOR) of bytes 3 through 65. This value is 
compared with a checksum produced by the Motorola processor. If the two values do 
not match, the position is disregarded. Each binary format message is terminated with 
a carriage return and line feed (ASCII characters 13 and 10). By monitoring for these 
bytes, the end of the message is recognized so that processing can begin on subsequent 
messages. 

c. GPS Fixing 

There are two types of GPS fixes which must be considered in the design of 
SANS. During transit phase, real-time processing of GPS messages is required to 
maintain navigation accuracy of 100 meters. The ultimate goal of SANS is to provide 
GPS information for post-processing and combination with DR submerged navigation 
ascent vector to allow the location of submerged objects with an accuracy of 10 
meters. 
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The message header distinguishes the message format as described earlier so 
that only position format messages are processed real-time by SANS for navigation 
updates to produce instances of NAV_DATA_TYPE. During transit mode, several 
instances of NAV_DATA_TYPE will be produced while the AUV is surfaced. When 
the accuracy of the fix is considered adequate by the main procedure, GPS processing 
will be terminated until the next update request from the AUV. This accuracy 
assessment will eventually be based on PDOP and relation to previous positions 
through a Kalman filtering technique. 
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V. SOFTWARE TESTING 


A. INTRODUCTION 

In order to provide confidence in the software architecture develop>ed for SANS, a 

systematic and lh('rough if not exhaustive testing process is essential. Booch (Ref. 11] 

states two goals in the design of software tests: 

Primary goal : Preventing bugs from entering code by making potential mistakes 
and misunderstandings visible and by identifying incomplete 
requirements/design. 

Secondary goal : clearly identifying if there is a bug by causing that bug to 
produce a result that conflicts with a specified or expected result. 

SANS is a multi-year project which will progressively incorporate new technology 

components to achieve improved accuracy. The solution dc.scribed in this interim 

SANS de.sign considers primarily the tactical mission execution of underwater 

mapping. The architecture will expand in the next generation to include the strategic 

considerations involved in transit to and from the target area and optimization of the 

mapping phase. 

The interim SANS originally utilized Ada tasking to permit concurrent operation of 
DR Navigation and GPS processing. This concurrency was eventually eliminated 
since the calculation of the ascent vector and GPS processing occurs consecutively 
vice concurrently. The resulting structure is much less complicated at the highest 
level. 
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While the higher level architecture will pruhably undergo further radical changes to 
meet expanding requirements, modules developed in the interim system will be reused 
to provide a foundation for implementation of the next generation SANS. Due to the 
nature of development objectives and the elimination of concurrency, the testing 
approach here concentrates much more heavily on verifying the correct operation of 
individual modules than of the overall system. A functional (black box) testing 
approach is consistent with the objectives of ensuring modular correctness. 

B. CLASSIFYING REQUIREMENTS 

The software system requirements are developed from Section IV.B.l (Software 
Architecture ; Determining Requirements). Requirements can be classified according 
to the approach used to verify compliance. The four classification levels are non- 
testable, inspection (of source code), dynamic analysis (of variable usage, comments, 
etc.) and execution (of compiled code with selected test data). (Ref. 11) 

1. AUV monitoring shall be performed continuously during the mapping phase so 
that when an object of interest lias been located by the AUV, sufficient data may be 
recorded to determine the geographic position of the object through post-processing. 
This requirement can be verified by inspection and is satisfied through a loop in the 
main procedure which "idles" all processes until a position update request is received 
from the AUV. This loop continuously monitors an RS-232 serial connection with the 
AUV lor an update request message. Alter the update is complete, the loop is then re¬ 
entered until another request is received. 
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2. DR navigation and GPS processing shall remain inactive with GPS unpowered 
(except for a low voltage applied to preserve volatile memory) until the AUV requests 
a position fix. Satisfaction of this requirement with respect to software is verified by 
inspection of the source code which indicates that DR and GPS processing only occur 
lollowing an AUV update request. The hardware design must also ensure that power 
is physically removed from these devices between requests. 

?>. When an update is requested. AUV MONITOR shall initiate DR navigation and 
GPS processing, inspection verifies that upon receipt of an AUV update request, the 
AUV monitoring loop is exited so that DR and GPS processing can commence. DR 
navigation data is collected until the AUV is surfaced where GPS satellite range data 
is recorded. 

4. The GPS shall be initialized with the receiver in the Motorola proprietary 
binary formal with transmissions at a one second interval after the AUV requests a 
position fix. This requirement can be verified by inspection of source code and 
through execution of the initialization routine which initializes the receiver in the 
configuration which existed when power was last removed. 

5. The receiver shall be programmed to transmit position/status format messages 
during transit phase and satellite range format messages during mapping phase when 
initialized. This requirement has not yet been satisfied but can be verified by 
inspcc'ion. Q)mpliance will occur at implementation of transit phase during future 
research. 
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6. The host computer shall be configured to receive RS-232 serial communications 
with connection parameters specified from an input data file at run-time. This 
requirement is verified through inspection and execution of the serial communication 
procedure. 

7. Upon mission completion, the host machine configuration shall be restored to 
the state which existed prior to SANS execution. Inspection shows that the original 
interrupt masks and vectors are stored at initialization in the data section of the 
assembly language code for serial connections and gyro driver. These values are 
restored by CLOSE_SERIAL upon program termination. Prior to program execution, 
the DOS (disk operating system) program debug.exe is used to verify the current 
interrupt vector for affected hardware interrupt levels. After termination, DOS debug 
verifies that the vector table has been restored to its original condition. 

8. All information received through the serial connection by the host machine shall 
be written to non-volatile memory prior to real-time processing. Inspection of package 
body Motorola shows that this requirement is satisfied since each execution of 
READ_CHAR is followed by a write to the output file prior to any other processing. 

9. Position format messages shall be processed to determine the current position 
and PDOP for navigation updates and to determine the checksum to validate the 
particular message. Execution test cases are developed in Appendix F to ensure that 
position and PDOP are correctly interpreted. 
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10. DR navigation outputs shall include pitch attitude and heading in degrees and 
depth in meters. By inspection of the specification of DELTA_UPDATE, the inputs 
for DR navigation are confirmed. These values are recorded in non-volatile memory 
along with mission time. 

11. DR processing shall record output values with a precision commensurate with 
component accuracy and sufficient to satisfy system accuracy requirements specified in 
.section l.D.d. Chapter VI examines component and system accurracy to include an 
assessment of overall system performance. 

12. Gyro position shall be monitored continuously by a process transparent to 
SANS operation. Inspection of the assembly language device driver for tracking gyro 
rotation shows that interrupts generated from the phased quadrature input are used to 
trigger an interrupt .service routine to count valid pulses. The machine state is saved 
at each interrupt and restored after the interrupt is handled. Execution of benchmark 
processes to examine CPU processing limitations for handling interrupts from the gyro 
driver are detailed in Section V.D. 

13. The process shall take a pair of standard phased quadrature signals as inputs. 
This requirement is verified through inspection of the assembly language device driver 
for the gyro as in requirement 12. The signals are interfaced through pins 25 and 26 
of the Sapphire DB-37 connector. 

14. Valid pulse pairs [Fig. 4.3] shall be counted on a continuous basis with each 
unit representing +/- 0.4 degrees of rotation depending on the direction of rotation. 
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This requirement is satisfied through analysis in section V.D.l.a of the 3-state tracking 
algorithm |Fig. 4.4) contained in section V.E.2.a. Execution test cases contained in 
Appendix E ensure that the algorithm is correctly implemented. 

15. Invalid pulses from either signal (non-overlapping) are considered "noise" {Fig. 
4.4) and shall be disregarded in the pulse count. As in requirement 14, analysis 
verifies the correctness of the algorithm with execution test cases in Appendix E 
validating the implementation. 

16 The cumulative value of the pulse count shall be continuously available for 
interrogation by the main procedure for DR navigation. Verification of this 
requirement is accomplished through inspection of the assembly language gyro driver 
and inspection of the interface between the gyro driver and the main procedure. 

17. Sapphire A to D conversions shall be initialized from a data file containing the 
multiplexed channels to be used for heading and depth inputs. Inspection of the main 
procedure and package ANALOG shows that the A to D conversion channels are 
selected from the input data file A_TO_D.dat. 

18. Analog to digital conversion of analog heading and depth output shall provide 
12 bit accuracy (one part in 4096). Execution of a range of analog inputs from a DC 
power supply were used to correlate voltage levels with digitized outputs. Inspection 
of the implementation in package ANALOG shows that 12 bit accuracy is provided. 


51 





C. IDENTIFY IMPORTANT CASES AND SELECT TEST DATA 

1. Requirements 13 through 16 involve the accurate tracking of gyro rotation and 
is evaluated in two phases. The state transition tracking algorithm is first verified by 
informal proof in section V.D.l.a below. Test cases read from an input file are then 
executed to validate the implementation of the algorithm. Inputs with expected and 
observed results are contained in Appendix D. 

a. There are 4 cases to examine in the 3-state transition tracking algorithm as 
shown in Figure 4.4. Appendix D contains examples of each state transition ca.se 
along with results from test executions. 

In cases 1 and 3, valid rotation has been indicated by a state transition from 
state 1 (clockwise rotation) or from state 3 (counter-clockwise rotation) to state 2. 
This is illustrated in Figures D.l and D.2 respectively. The results of the test 
execution demonstrate that the pitch_count is correctly computed in each case. 

Figures D.3 and D.4 demonstrate that the algorithm correctly tracks a reversal in 
rotation as illustrated by a reversal in the order of rising edges in the gimbals output 
signals. 

In case 7 (ransilions, the machine is returning to state 1 or 3 from state 2. 
This is usually an indication that a valid rotation has occurred in the previous 
sampling and a new pulse has been detected from one signal input. Figures D.l 
through D.4 demonstrate that case 2 transitions are correctly discounted by the 
implementation. 
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In case 0, no state transition has occurred since the current state is the same 


as the last state. This is typically the case with noise in a single channel. Figures 
D.5, D.6 and D.7 demonstrate that no rotation is occurring in case 0 state transitions 
and also that this case is correctly discounted by the tracking algorithm’s 
implementation. 

Case 4 transitions are invalid state transitions between state 1 and state 3. 
This transition is caused by a pulse from one gimbals then the other where the pulses 
do not overlap. The likely cause of a case 4 transition is noise in both channels as 
illustrated in Figure D.8. Figure D.8 also demonstrates that this case is correctly 
discounted by the tracking algorithm. 

2. Requirement 8 calls for the correct interpretation of the latitude, longitude and 
PDOP from position formal messages. This requirement is evaluated through a test 
implementation of package MOTOROLA which reads a binary input file vice actual 
receiver messages. In this manner, all paths can be tested and a full range of edge 
cases can be executed. 

The range of latitudes is +/- 324,000,000 degrees in milliseconds. For 
longitude, the range is +/- 648,000,000 degrees in milliseconds. Test cases include 
positive and negative two’s complement values to exercise hemisphere interpretation 
and various message formats. Appendix E summarizes test cases with expected and 
observed results. 
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D. REAL-TIME PROCESSING VERIFICATION 

The elimination of concurrent processing from the main procedure in the interim 
SANS has greatly simplified the timing requirements at the highest level. In the 
lowest level assembly language procedures employing interrupts, a statistical analysis 
is conducted here to evaluate the adequacy of the software development machine to 
handle the expected interrupts and processing requirements. Growth capability is 
examined for handling multiple gyros. 

The software development machine was benchmarked for 10,000 sine operations to 
evaluate the effect of the interrupt service routine on central processor unit (CPU) 
availability. Execution of the sine operations with no other significant load required 
306.795 seconds with a standard deviation of 0.085 seconds. After the sine operations 
were benchmarked, the driver for the gyro was loaded. Both the pitch and roll axis of 
the vertical gyro were interfaced through the single interrupt input channel to simulate 
multiple interrupt inputs. 

The time to execute the same 10,000 sine operations with both gyro axis highly 
excited increased by 6.035 seconds with a standard deviation of 0.41 seconds. This is 
an increase of only 1.97 percent in execution time. The only other time critical 
processing requirement in SANS is the RS-232 (9600 baud) serial line connection 
which imposes a similar CPU load. The software development machine should handle 
such loads with no problems. These conditions should be reassessed when the 
software and hardware arc moved to the ESP-8680 target machine. 
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VI. HARDWARE CHARACTERISTICS 


All accuracy assessments made in earlier research are based on manufacturer’s 
technical specifications. In order to validate these findings, field and laboratory test 
data are presented here with statistical analysis of those results. This chapter 
concludes with an a.ssessment of overall system performance based on these findings. 

A. MOTOROLA GPS RECEIVER 

A major limiting factor in SANS accuracy is the accuracy of the GPS receiver. 
Extensive GPS data was collected with the Motorola PVT6 receiver to assess the 
impact on system performance. There are two broad test categories conducted in this 
research involving GPS. These tests evaluate the receiver for accuracy in a dynamic 
environment and for acquisition time in a static environment. The major limitation on 
the test results presented here is the absence of differential processing which has been 
deferred to future research. 

1. GPS DYNAMIC TESTS 

GPS dynamic tests were conducted onboard a modified electric golf cart (called 
the lest vehicle). This platform is capable of a lop speed of approximately 5 
meters/second and provides both 12 volt DC from a deep marine battery and 110 volt 
alternating current (AC) through a DC to AC converter. 

In order to a.ssess the accuracy of field data, the test vehicle is specially 
instrumented to permit accurate tracking through a surveyed test track. Data is logged 
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by a general serial I/O handler developed by Dr. James Clynch called GEORGE. This 
program provides a wide variety of functions including a printer p>ort status (PPS) 
which logs changes in the condition of the instrumentation devices interfaced through 
the printer port. [Ref. 15] 

Test vehicle instrumentation includes an infrared (IR) sensor which detects 
reflective IR strips on the surveyed test track. The position of the centroid of the IR 
strips is known to an accuracy of approximately 1 centimeter. The vehicle is also 
equipped with a trailing bicycle wheel with magnetic sensors for recording 
longitudinal distance travelled and a "button" which allows the operator to manually 
mark some event. Dynamic tests were conducted at Frilzsche Army Air Field (AAF) 
at Fort Ord, California. The test track was surveyed to an accuracy of approximately 
1 centimeter (cm). 

The objective in the dynamic GPS data collection is to assess the dynamic 
accuracy of the Motorola GPS receiver relative to expected SPS accuracy. Fourteen 
test runs over a one hour period were conducted to gather data. Figure 6.1 illustrates 
the positional accuracy of the test runs relative to the known course. This is a plot of 
unprocessed GPS without respect to time. 

In order to a.ssess the accuracy of the GPS data, a comparison was made with 
test track events recorded by GEORGE’S operation PPS. This time history will be 
called "truth data" due to its known relative precision of 1 centimeter. The host 
computer was corrected to universal coordinated time (UTC) via modem connection to 
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Figure 6.1 : Test Data Results Relative to Known Positions 

permit correlation of GEORGE’S time reference with GPS time (also recorded in 
UTC). 

The GPS binary data was processed through package Motorola’s test procedure 
to convert data of interest to character format for comparison with GEORGE’S "truth 
data". GEORGE’S PPS data was similarly processed to allow for comparison. The 
raw PPS file was first processed by package BIW (button, IR, Wheel) to identify each 
event according to its source. The BIW file was then manually processed with 
reference to the sequence of events recorded at the time of test. The purpose here is 
to identify the specific location of each IR marker in the "truth data" file for 


57 









comparison with GPS positions. The velocity was computed based on wheel 
revolutions with respect to elapsed time. 

Finally, the processed GPS and truth data were correlated using a routine 
developed by Dr. Clynch called DIFDAT. This procedure compares a specified 
parameter, in this case time, in each file to interpolate between events occurring 
asynchronously in the two files. This permits an assessment of the accuracy of the 
GPS data relative to the known positions in the truth data even though the position 
limes do not correlate exactly. [Ref. 16) 

As can be seen in Figures 6.2 and 6.3 the standard deviation of error is 18.7 
meters in latitude and 13.2 meters in longitude. This yields a positional error of 22.9 
meters one rms which is well within the expected range for SPS accuracy. North and 
east velocity components were similarly processed from the raw GPS and truth data 
files. The error is 0.21 metcrs/second for north velocity components and 0.17 
meiers/second for east velocity components. This yields a rms velocity error of 0.27 
meters/second. 

2. GPS STATIC TESTS 

Static tests were conducted using the Motorola receiver to assess acquisition 
lime and first fix accuracy. These tests utilize an antenna mounted on the roof of 
Spanagel Hall at a surveyed location. This site provides a horizon relatively free from 
obstructions. 


58 





LATITUDE DEVIATIONS 



-STANDARD OCVUTCN 


Figure 6.2 : GPS Dynamic Data Latitude Deviations 


LONGITUDE DEVIATIONS 



TIME (SECONDS OF DAY) 
(Thounndi) 

- STANDARD OCVtATION 


Figure 6.3 : GPS Dynamic Data Longitude Deviations 
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GEORGE’S operation PPS was used to program a relay box which interrupts the 
12 volt main power supply to the GPS receiver tor a specified duration and interval. 
However, the 5 volt regulated keep alive power is supplied continuously to preserve 
the most recent coordinates and constellation in SRAM volatile memory. GPS data is 
logged using the manufacturer’s software to ease processing requirements due to 
compatibilty with commercial spreadsheets. 

Appendix F illustrates the results t'f these tests as a function of the amount of 
time which the receiver was unpowered. These times range from 90 seconds through 
6 hours. The results are summarized in Table 6.1. Although time to first fix (TTTF) 
is rclati /ely stable through the longest test (6 hours), the accuracy of the first fix 
degrades considerably beyond 30 minutes off 

TABLE 6.1 : GPS STAl IC TEST RESULTS SUMMARY 


RECEIVER TIME 
UNPOWERED 

ACQUISITION 
TIME (rms) 
SECONDS 

FIRST FIX 
ERROR (rms) 
METERS 

NUMBER i 
of 

SAMPLES 

90 SECONDS OFF 

29.1 

46.4 

45 

10 MINUTES OFF 

29.6 

51.2 

30 

30 MINUTES OFF 

29.2 

48.6 

39 

1 HOUR OFF 

28.7 

60.9 

33 

3 HOURS OFF 

42.0 

75.2 

23 

6 HOURS OFF 

49.4 

25.0 

15 
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Analysis of the raw GPS data indicates that the predominant factor in this 
accuracy degradation is occasional poor geometry in the first set of satellites acquired 
by the receiver. Inspection of tracked satellites indicates that the geometry improves 
quickly after tracking the first satellite due to rapid acquisition of additional satellites. 
However, this process continues to slow as time unpowered increases due to increasing 
frequency of changes in the currently visible satellites. 

The static test results indicate that the ITT F is relatively stable below 30 
seconds until the time off exceeds one hour. The first fix accuracy deteriorates 
steadily as a function of time off with the exception of 6 hours off where the TTTF is 
excessive. The maximum time between GPS updates should not normally exceed 
approximately 30 minutes in order to improve first fix accuracy. At this update 
frequency, antenna exposure can be limited to approximately 30 seconds maximum. 
Lxingcr intervals between updates are possible but will necessitate longer antenna 
exposures to obtain a position update of reasonable accuracy. 

These test results confirm the manufacturer’s specifications in Appendix A and 
indicate that the objectives for the SANS transit phase are easily attainable. Further 
testing using differential processing techniques is required to validate feasibility of the 
accuracy requirements for the mapping phase. 

B. GYRATION GYROENGINE 

Testing of the gyroscopes was conducted at the A/\F test track. The testing was 
conducted in cooperation with the manufacturer of the gyro and consisted of 10 test 
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circuits on the instrumented test track. Only the directional gyro was evaluated due to 
the two-dimensional orientation of the test track. Gyro data was recorded utilizing the 
manufacturer’s software. GEORGE was again used to record "truth data" from the 
lest vehicle. Processing of the "truth data" was conducted in the same fashion as for 
the dynamic GPS experiments. This data was then compared manually with the gyro 
data to determine the cumulative error for each individual run. 

The test gyro was powered ty 12.0 volts during 8 of 10 test runs. Single test run 
were conducted at 5.0 volts and 15.0 volts. During steady state operations at 12.0 
volts, the mean drift rate was 2.3 degrees per minute (dpm) with a standard deviation 
of 2.2 dpm yielding 3.2 dpm rms. This is slightly higher than the product 
specification for Scorsby drift rates of 1.5 dpm typical and 3.0 dpm maximum [Ref. 

131. 

During the 9.2 meter radius turn at the comer of the test track with an average 
speed of 3.0 meters per second, the average acceleration was computed to be 0.16 G’s 
or 1.6 meters per second per second. The observed drift rate was 25.4 dpm with a 
standard deviation of 15.6 dpm yielding 29.8 dpm rms. The expected drift rate at the 
advertised specification of 3.0 degrees per second per G for the computed 0.16 G is 30 
dpm. These observed and expected results here are consistent and demonstrate that 
acceleration is the dominant factor in gyro drift rate. 

The result of a single test run at 5.0 volts DC is particularly noteworthy. Although 
steady state drift rate was consistent with other tests, the drift rate in turns was 120 
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dpm. The high drift rale at this low motor speed is unacceptable for the intended 
applications in SANS. Since the SANS driver for the gyro was developed for 
execution at 5.0 volts, future research should concentrate on expanding the envelope of 
the SANS gyro driver with higher voltages and the resultant higher motor speeds. 
Further testing is also necessary to validate the performance of the pitch axis of the 
vertical gyro. 

C. DEPTH TRANSDLCER 

The Omega Inc., depth transducer was evaluated on a 50 PSl Chandler Engineering 
dead weight tester. Tfiis test bench utilizes a hydraulic cylinder to pressurize the 
diaphragm of the depth transducer. Pressure is generated in increments of 5 PSI by 
adding calibrated weights to pressurize the cylinder. The depth transducer’s output 
was measured by a digital voltmeter to 3 decimal points accuracy (milli-volts). 

Figure 6.4 illustrates the results of the pressurization schedule. Due to the 
minimum pressurization of 50 PSI, no measurements are possible between ambient and 
50 PSI. The maximum deviation from a linear function in the digital output is 
observed at the 50 PSI mid-point. The deviation at this point is 16 milli-volts (3.516 
volt average over 4 runs with 3.499 volts expected). This deviation correlates to 0.46 
percent, which is within the 0.5 percent advertised linearity accuracy. [Ref. 17] For 
SANS, t’.is translates into 0.335 meter accuracy for full depth excursions. 
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Figure 6.4 : Depth Transducer Calibration Results 


D. SYSTEM PERFORMANCE ASSESSMENT 

1. GPS Performance 

Although not ail components of the system have yet been evaluated in their 
operational mode, some assumptions can be made to assess the overall performance of 
the interim SANS. The results of the GPS static testing certainly indicate that the 
target acquisition times and fix accuracy are attainable for update intervals of less than 
30 minutes. These results also indicate that differential post-processing should permit 
GPS positions to be determined to an accuracy of 2 to 4 meters. 

2. DR Navigation Performance 

The accuracy of the computation of the horizontal distance travelled is affected 
by the accuracy of th ’ depth transducer and gyro (or accelerometers) during the ascent. 
The maximum effect of the pitch attitude inaccuracy would occur whMe SANS is level 


64 












(pilch attitude = 0 degrees) since the value of tangeni(theta) in the denominator of 
(Equation 3.2) approaches 0.0 at zero degrees. This would result in an error of infinite 
magnitude lor even small errors in pitch attitude measurement. Similarly, heading 
measurement inaccuracy affects system accuracy most when the pitch attitude is very 
shallow since this results in a large horizontal distance travelled and high gyro drift. 

The differential approach used here to assess the overall accuracy of SANS was 
developed by Dr. J. R. Clynch. [Ref. 18) The analysis uses the manufacturer’s 
technical specification in Appendix A except in the case of the gyro drift rate where 
the slightly higher lest results are used. The drift rale for the pilch axis of the vertical 
gyro is assumed to be the same as that calculated for the directional gyro. 

Recall from Figures 3.1 and 3.2 and the text that the climb angle (theta) is 
measured by the pitch axis of the vertical gyro. Alpha is the AUV heading which will 
be measured by compass and directional gyro in future development. Let h represent 
the change in depth measured by the depth transducer and let s^, represent the 
horizontal distance travelled by the AUV from a submerged object of interest during 
its ascent to the surface where the GPS position will be determined. Then as in 
equation 3.2: 





By taking the first derivative: 


ds^^dh 


cos(6) 

sm(0) 


sin^(0) 


-dd 


( 6 . 2 ) 


Because the depth and pitch angle errors are uncorrelated, the sum of the 
magnitude of the two terms in equation 6.2 can be used to estimate the size of the 
error in slant range. [Ref. 18] Equation 6.3 yields the position error due to precession 
in the heading gyro. 


AOU=Sff*da*dSff (6.3) 

Where AOU is the Area of Uncertainty. 

The AOU will be the slant range error times the heading error. The radius of a 
circle covering the same area will be used as an estimate of the positional error. [Ref. 
18] Figure 6.5 illustrates the computation of the positional error. 



SUBMERGED OBJECT 
OF INTEREST 


Figure 6.5 : Computation of Inertial Measurement AOU 
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Table 6.2 tabulates the results of error approximations for varying climb angles. 
A transit from the depth transducer’s maximum depth is assumed with a maximum 
gyro drift rale of 3.2 dpm as calculated above (assuming no significant accelerations). 
The GPS error is assumed to be 4.0 meters rms. 


TABLE 6.2 : SANS SYSTEM ACCURACY FROM 70 METERS 


CLIMB ANGLE 

20 degrees 

25 degrees 

30 Ddgrees 

TIME TO CLIMB 

39 seconds 

32 seconds 

27 seconds 

GYRO PRECESSION 

2.1 degrees 

0.036 radians 

1.7 degrees 

0.03 radians 

1.4 degrees 
0.025 radians 

AREA OF 
UNCERTAINTY 

140.0 meters^ 

49.0 meters* 

11.6 meters^ 

POP-UP ERROR rms 

11.8 meters 

7.0 meters 

3.4 meters 

TOTAL ERROR rms 
(GPS + POP-UP) 

12.5 meters 

8.0 meters 

5.3 meters 


The objective for accuracy during mapping phase of 10 meters rms are achieved 
by SANS during transits from its maximum depth of 67 meters only when the climb 
angle is slightly greater than 30 degrees. NPS AUV2 is restricted to much shallower 
climb angles but also to depths of less than approximately 10 meters. This depth is 
more typical of the application expected for SANS. As indicated by Table 6.3, climb 
angles greater than 12 degrees should satisfy the accuracy objectives of SANS. 
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TABLE 6.3 SANS SYSTEM ACCURACY FROM 20 METERS 


CLIMB ANGLE 

10 degrees 

12 degrees 

15 degrees 

TIME TO CLIMB 

23 seconds 

19 seconds 

15 seconds 

GYRO PRECESSION 

1.2 degrees 

0.02 radians 

1.0 degrees 

0.017 radians 

0.8 degrees 

0.014 radians 

AREA OF 
UNCERTAINTY 

101 meters^ 

46.3 meters^ 

4.4 meters^ 

POP-UP ERROR rms 

10.0 meters 

6.8 meters 

2.1 meters 

TOTAL ERROR rms 
(GPS + POP-UP) 

10.8 meters 

7.9 meters 

4.5 meters 
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VII. CONCLUSIONS 


A. SOFTWARE ARCHITECTURE 

A primarily object-oriented design approach is used to implement the design of 
SANS. The major operations performed by SANS are 

- Monitoring the AUV for a position fix request 

- Navigation data-logging for dead reckoning (DR) navigation (post-processed to 
determine ascent vector), and 

- GPS data-logging for post-processed positional information. 

The first and third of these are implemented primarily through a serial communication 
line routine designed by Dr. Se-Hung Kwak. The GPS processing routine was 
redesigned at the lowest level to accommodate the proprietary binary format used by 
Motorola. DR navigation implements a navigation data logger for hardware 
components of an inertial navigation system. This data includes the results of A to D 
conversions of compass and depth transducer outputs and D to D counting operations 
associated with phase and quadrature digital output signals from a miniature spin gyro. 
D to D operations are implemented in assembly language for higher efficiency due to 
their high frequency. A to D operations are implemented in Ada. 

A major goal in the implementation of SANS has been modularity of code. As 
new technology is incorporated, this approach facilitates redesign of the entire system 
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with many modules being reused or replaced. Complexity management in a 
moderately large software system like SANS is also enhanced. [Ref. 11] 

B. SOFTWARE TESTING 

Requirements based testing is applied to SANS in order to verify the proper 
operation of key modules in the implementation. A primarily functional (black box) 
testing approach is u.scd in keeping with the design goal of modularity to ensure that 
individual modules may be replaced or reused without side-effects on other modules. 
Some of the key findings are summarized below. 

1. GPS MESSAGE TRANSLATION 

a. All paths in package Motorola are reachable through the various test cases 
represented in Appendix E. All outputs are consistent with expected results. 
Validation of checksums are not yet implemented. This requirement will be essential 
for real-time processing of the position format messages in the implementation of the 
transit phase of the mission. 

b. Values falling outside the ranges of +/- 648,000,000 for longitude and +/- 
324,000,000 for latitude are possible if messages are incorrectly translated. Although 
testing for this situation is not specified as a requirement, correction is advisable and 
is accomplished by declaring legal ranges for input values. 

2. GYRO DRIVER 

a. Gyro rotation is correctly tracked through all possible state transitions as 
demonstrated in Appendix D. This result is consistent with many hours of direct 
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observation of pre-production gyros under dynamic operating conditions in which only 
low drift rate precession has been observed. 

b. Interrupt handling for the gyro is easily accommodated in the software 
development machine. Real lime processing requirements should be reassessed when 
the software and hardware are moved to the ESP-8680 target machine. 

C. HARDWARE CHARACTERISTICS 

All components meet or exceed all critical specifications except for the gyro where 
the drift rate of 3.2 degrees per minute is slightly higher than the maximum specified 
(3.0 degrees per minute). The error analysis conducted in section VI.D uses the more 
conservative results for the gyro rather than manufacturer’s technical specifications. 
Further research is necessary to validate the performance of the pitch axis of the 
vertical gyro, the compass accuracy and the accuracy of post-processed GPS. 

The error analysis indicates that all objectives of the interim SANS are achievable 
according to research conducted to date. The only major restriction associated with 
the interim SANS system is the requirement that the AUV must be restricted to a 
climb angle of slightly greater than 30 degrees from the SANS’ maximum depth of 70 
meters. During climbs from a more typical depth of 20 meters, a climb angle of 
approximately 12 degrees will deliver acceptable accuracy. These restrictions are 
necessary in order to ensure acceptable positional accuracy which is degraded by the 
increasing degree of gyro precession during the long ascent paths associated with 
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shallow climb angles. These restrictions will limit a technology demonstration to 
more shallow depths or to AUV’s capable of attaining large climb angles. 

D. FUTURE RESEARCH 

1. SOFTWARE DEVELOPMENT 

All software testing so far has been confined to the software development 
machine. The next critical phase in the software development is to evaluate the 
performance in the ESP-8680 target machine. Additional hardware is necessary to 
support the operation of SANS during this process. The A to D converter selected 
should have two interrupt input channels so that the yaw axis directional gyro may be 
tracked to improve heading accuracy during high turn rates. The current 
implementation of SANS is restricted to the pitch axis of the vertical gyro only. 

The primary focus of this research has been the conduct of the mapping phase 
of the SANS mission. This only requires that satellite range format messages be 
recorded in order to permit the AUV’s location to be determined through post¬ 
processing. In order to execute the transit phase of the mission, the Motorola GPS 
receiver must be reinitialized during the mission to transmit position format messages. 
This will be accomplished through transmission of preformaited binary messages using 
package SERIAL’S function WRITE_CHAR for writing characters through the serial 
communication. 


72 






2 GYROSCOPES 


As staled above, turther research is necessary to validate the performance 
characteristics of the pilch axis of the vertical gyro. This will most likely require 
laboratory experiments using a servo-driven till table. [Ref. 19] 

All testing with the device driver for the gyro thus far has been accomplished 
using pre-production items on loan from Gyration, Inc. During initial operation of the 
production issue gyros with the software development device driver, some 
inconsistencies in tracking gyro rotation were observed. Compatibility of the driver 
with the.se nroduction items must be assessed. Expansion of the driver’s envelope 
must also be addressed to ensure proper operation at higher input voltages and the 
corresponding higher motor speeds. Clearly, the field tests indicate that even under 
moderate acceleration at the low motor speed associated with an input of 5.0 volts, the 
drift rate is unacceptable for the application intended here. Further research may be 
necessary to develop a solution incorporating the use of accelerometers to dampen the 
effect of high frequency pitch excursions. 

Finally, an applicability study of a new small but high performance IMU 
package developed by Systron Donner Corporation is proposed for SANS. This unit is 
expected to meet the space and power requirements of SANS and easily improve the 
system accuracy. [Ref. 19] 
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APPENDIX A 


TECHNICAL SPECIFICATIONS 


A. SAPPHIRE CONVERTER 


Analog Section: 

A/D resolution; 

Linearity error: 

Differential linearity error: 

Conversion time: 

Maximum conversion rate*: 


Input channels: 
Expansion capabality: 


12-bits (1/4096) 

1/2 LSB max 

12 bits (no missing 
codes) 

20^s max 

15kHz with clock 
timing 

30kHz in software 
burst mode 

8, single-ended 

128 channels, 

differential 


Input ranges: 

Input range selection; 

Input impedance; 

Channel-to-channel isolation: 

Input overvoltage protection: 

Digital Section; 

Digital I/O; 31 bits, 

Direction: 4 out, 3 

Software 


±5V, +10V, O-IOV 
Software 
2.5MQ min 
68dB min 
+ 32V 

TTL-compatible 
in (Jl) 

configurable (J2) 


76 








Output 

voltage 

levels: 




Jl: 

Low 

O.OV 

min. 

0.5V max @ 

8mA 


High 

5.0V 

max, 

2.7V min @ 

400(iA 

J2: 

Low 

O.OV 

min. 

0.45V max @ 1.5mA 


High 

5.0 V 

max. 

2.4V min @ 

lOOfxA 

Input 

voltage 

levels: 




Jl: 

Low 

O.OV 

min. 

0.8V max 



High 

2.0V 

min. 

5.5V max 


J2: 

Low 

-0.5V min 

, 0.8V max 



High 

2.0V 

min. 

5.5V max 



Interrupt input: 


TTL-compatible 
rising-edge triggered 


Counter/Timer Section: 


No. of counters: 


3, 16 bits wide each 


Type; 


Presettable synchronous 
down counters 


Maximum count frequency: 8MHz 

Internal clock source: PC clk-i-2, PC clk-^-4 

(jumper selectable) 


Miscellaneous: 

Operating temperature: 0-60"C 

Dimensions: 4.2" x 7.0" 


♦These specifications are derived from tests on a 
12MHz 80286-bayed AT compatible. Maximum speed will 
vary depending on the speed of the host computer. 
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B. ESP-8680 

Processor 14 MHz 5-volt "8680" (8086 

equivalent) 

Serial Port RS-232 

Graphics CGA (Color Graphics Adapter) or 

LCD (Liquid Crystal Display) 

Memory 256K x 8 EPROM or Flash Memory 

512K or 1MB DRAM (8-bit or 16-bit 
wide memory path) 

Memory Option Expansion board adds up to 

16MB DRAM 

Bus Interface ISA (Industry Standard Architecture) 

Form Factor 1.7" x 5.2" (13.2cm x 4.3cm) 

Power Consumption Draws from 1 mA (sleep mode) to 

300 mA (peak load powering 
back-lit LCD and peripherals) 
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C. MOTOROLA PVT6 

Receiver Architecture 

Tracking Capability 
Dynamics 

Aquisition Time 

(Time to First Fix, TTFF 

Accuracy 

Operating Temperature 
Physical Dimensions 

Weight 

Switched Power 

Keep-Alive Power 
Power Consumption 

MTBF 


6-channel 
LI 1575.42 MHz 

6 simultaneous satellite 
vehicles 

Velocity 1000 Knots 

(514m/sec) 
Acceleration 4g 

24 sec. typical TTFF (with 

current almanc, position, 
and time) 

54 sec. typical TTFF 

Less than 25 meters, SEP 
(without SA) 

-30*C to +80"C 

3.94 X 2.75 X 0.65 inches 
(100 X 70 X 16.5 mm) 

4.5 ounces (128 grams) 

9-16 Vdc or 
5 ± 0.25 Vdc 

4.75 - 16 Vdc; 0.3 mA max 
Typical 

1.3 W @ 5Vdc input 
1.8 W @ 12Vdc input 

65,000 hours (estimated) 


79 







D. GYRATION GYROENGINE 


Performance 

motor speed; 8,000 revolutions per minute (RPM) to 
50,000 RPM selectable by input voltage 
Scorsby drift: 




25,000 RPM 

50,000 RPM 

1 

o 

o 

n 

Typical 

Maximum 

6.0“/min. 
15.0"/min. 

5.0"/min. 
12.0"/min. 

+25"C 

Typical 

Maximum 

2.0"/min. 
5.0"/min. 

1.5"/min. 
3.0"/min. 

+80"C 

Typical 

Maximum 

4.0"/min. 

10.0"/min. 

3.0*/min. 
7.0"/min. 


Static Drift 

-40“C to +80'’C; typical 0.5°/min., maximum l.OVmin. 
at 25,000 to 50,000 RPM 

Precession 

erection system; pendulous inner gimbal 
precession period: 135 seconds 

precession damping: precession decreases 37% each 
precession period 

precession angle due to horizontal acceleration; 
3°/sec./G, equivalent to 0.14"/I mile/hour 
change in speed 

Optical Encoder Output 

encoder resolution; O.l" 

encoder linearity; ±1% of full scale maximum 
sensor slew rate: 260°/sec. 
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Power 

DC supply voltage; 4V to 12V selects motor speed 
maxium DC starting current; 

200 mA at 5V 

500 mA at 7V 

700 mA at 9V 

maximum DC running current; 

50 mA at 5V corresponds to 10,000 RPM 
125 mA at 7V corresponds to 25,000 RPM 

350 mA at 9V corresponds to 50,000 RPM 

Environmental 

operational temperature range; -40*C t +80“C 
humidity; 80% relative 

pressure altitude; -1,000 ft. to 40,000 ft. 
shock resistance; 400 G's, 8 mS half sine wave 
pulse duration (all axes) 
vibration; 2 G's RMS (20 Hz to 2,000 Hz) 

Physical 

dimensions; 1.3 in. maximum diameter 
1.75 in. maximum length 
weight; 1.5 oz. 

external; molded optical-grade polycarbonate with 
butyl rubber expansion seal 
internal; gimbal floatation fluid (Brayco 1721 
aerospace low-viscosity vacuum oil) 

Service Life 
40,000 hours 
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E. KVH ClOO DIGITAL COMPASS 

Accuracy 
Repeatability 
Resolution 
Dip Angle 

Tilt Angle 
Electrical Power 

Size 

Weight 

Environmental Performance 

Digital Interfaces 
Analog Outputs 


SENSOR 

±0.5* or ±10 mils RMS 

±0.2* or ±5 mils 

0.1° or 5 mils 

±80° Maintains stated 
accuracy after autocal 
over ±80° Magnetic Dip 
Angle 

±16° Dev.= ±0.3° RMS 
±45° Dev.= ±0.5° RMS 

Input Voltage: +8 to +20 VDC 
or +20 to +30 VDC 
(user selectable) 
Current Drain: 20 mA DC; 

nominal 

1.80 X 4.50 X 1.10" 

(4.6 cm X 11.4 cm x 2.8 cm) 

2.0 ounces (57 grams) 

Operating Temp.: -22°F to 

+122°F 
(-30*C to 

+50°C) 

Vibration: 30 minutes random 
MIL-STD-810 

Shock: Handling shock per 
MIL-STD-810 

Standard RS232 

Bidirectional Serial Data 

Sine/Cosine: Sine/Cosine 

output voltage +2.5V±1.0V 
OR 

Linear Voltage: 0 to +3.6VDC 
into lOK Ohm minimum load 
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F. OMEGA PX176-100PSIS 


PAftAMETER 

MIN 

TYP 


BBHII 

Full Scale Output 
(FSO) @ 25°C 

4.90 



Vdc 

Null Offset @ 25“C 

.85 


1.15 

Vdc 

Linearity (Best Fit) 


±.2 

+ .5 

%FSO 

Hysteresis 


+ .25 


%FSO 

Temperature Error 

Null 0’ to 85“C 


+ .01 

+ .02 

%FSO/ 

"C 

-55“ to 0“C +85“C 
to 105“C 


+ .02 


%FSO/ 

‘C 

Sensitivity 0" to 

85“C 


+ .01 

+ .02 

%FSO/ 

“C 

-55“ to 0“C +85“C 
to 105“C 


+ .02 


%FSO/ 

“C 

Stability (1 year) 


+ 1.0 


%FSO 

Frequency Response 


10 



Supply Voltage 

9 


20 

Vdc 

Supply Current 
(Quiecent) 


15 


mA 
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APPENDIX B 


SOURCE CODE 


_ ★★*■*★***★***★*★**★★**★★★*************★*******★*****★***★*★*♦*** 

File Name : SANS.A 
Author ; Lcdr C. D. Stevens 
DATE : 12/3/92 

Adapted from SNDL.a authored by Se-Hung Kwak 
Comments ; SANS consists of 3 major operations 

— AUV_MONITOR is a busy wait 

while other operations are idle 
AUV_MONITOR waits for a position update 
request 

DR NAVIGATION consists of logging DEPTH, HEADING 

— and PITCH along with the current time in small 

time increments for post-processing 

INIT_PROCESS_GPS initializes the Motorola GPS 
and PROCESS_GPS_DATA logs all Motorola pro¬ 
prietary Binary Messages for Post-processing 
.._★***★*★★*★*****★**★*★*★***★♦★★**♦★★♦★★★★★★★*★★★★*★★★♦**★*****★* 

with NAV_DATA, CALENDAR, P_AUV, P_GPS, A_to_D, tty, text_io, 
gyro_cnt, MOTOROLA* 

use NAV_DATA, CALENDAR, P_AUV, P_GPS, A_to_D, tty, text_io, 
gyro_cnt, MOTOROLA; 

procedure SANS is 

package INTEGER_INOUT is new INTEGER_IO(INTEGER); 
package FLOAT_INOUT is new FLOATIO(FLOAT); 

U5?° INTEGER_INOUT, FLOAT_INOUT; 


GPS_DATA ; NAV_DATA_TYPE; 

DIGITAL_HEADING, DIGITAL_DEPTH ; INTEGER; 

HEADING, HDG_CHAN, DEPTH, DEPTH_CHAN, PITCH_COUNT ; INTEGER; 
PITCH_DATA, HDG_DATA, DEPTH_DATA ; FILE_TYPE; 

GPS_FILE : BYTE_FILE.FILE_TYPE; 

FIX_SECONDS : DURATION; 

FIX_TIME ; TIME; 

GOOD_POSITION, UPDATE_REQUESTED ; BOOLEAN := FALSE; 
begin 

BYTE_FILE.OPEN{GPS_FILE, MODE => BYTE_FILE.OUT FILE, NAME => 
"GPS.DAT"); 

OPEN(PITCH_DATA, MODE => OUT_FILE, NAME => "PITCH.DAT"); 
OPEN{HDG_DATA, MODE => OUT_FILE, NAME => "HDG.DAT"); 
OPfiN(DEPTH_DATA, MODE => OUT_FILE, NAME => "DEPTH.DAT"); 
A_TO_D_PARAMETERS(HDG_CHAN, DEPTH_CHAN); 

INIT_PROCESS_GPS_DATA; 

INIT PROCESS_AUV_DATA; 
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INIT_DIGITAL_COUNTER; 


loop 

PROCESS_AUV_DATA(UPDATE_REQUESTED); 

CURRENT_DIGITAL_VALUE(HDG_CHAN, FIX_TIME, DIGITAL_HEADING); 
— Convert Digital Heading to a compass reading 
HEADING := CURRENT_HEADING(DIGITAL_HEADING); 

FIX_TIME ;= CLOCK; 

FIX_SECONDS ;= SECONDS(FIX_TIME); 

PUT(HDG_DATA, HEADING); 

PUT(HDG_DATA, FLOAT(FIX_SECONDS)); 
put(heading); 

text_io.put_iine("heading"); 

NEW_LINE(HDG_DATA); 

CURRENT_DIGITAL_VALUE(DEPTH_CHAN, FIX_TIME, DIGITAL_DEPTH); 
— Convert Digital Depth to actual Depth 
DEPTH := CURRENT_DEPTH(DIGITAL_DEPTH); 

PUT(HDG_DATA, HEADING); 

PUT(HDG_DATA, FLOAT(FIX_SECONDS)); 
put(heading); 

text_io.put_iine("heading"); 

NEW_LINE(HDG_DATA); 

PITCH_COUNT := READ_PITCH; 

PUT(PITCH_DATA, PITCH_COUNT); 

PUT(PITCH_DATA, FLOAT(FIX_SECONDS)); 
put(pitch_count); 
text_io.put_line("pitch"); 

NEW_LINE(PITCH_DATA); 

PROCESS_GPS_DATA(GPS_DATA, GOOD_POSITION, GPS_FILE); 
exit when GOOD_POSITION or tty.char_ready; 
end loop; 

BYTE_FILE.CLOSE{GPS_FILE); 

CLOSE(PITCH_DATA); 

CLOSE(HDG_DATA); 

CLOSE(DEPTH_DATA); 

SHUTDOWN_PROCESS_GPS_DATA; 

SHUTDOWN_PROCESS_AUV_DATA; 

RESTORE_INTERRUPTS; 

end SANS; 
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File Name : AUV_MON.A 
Author : Lcdr C. D. Stevens 


DATE : 5/15/93 

Comments : Adapted from P__GPS by Dr. Se-Hung Kwak to 

implement a serial line communication with an 
AUV which will request a GPS/Position Update 




— Nav_data contains the declarations for the Nav Data record 
format 

package P_AUV is 

procedure init_Process_AUV_Data; 
procedure SHUTDOWN_Process_AUV_Data; 

procedure Process_AUV_Data(UPDATE_REQUESTED : in out BOOLEAN); 
end P_AUV; 

— serial is an assembly language program which buffers incoming 

— serial stream data 
with TEXT_IO, SERIAL; 
use TEXT_IO, SERIAL; 

package body P_AUV is 

LOCAL_TIME_DIFF, RECEIVER_TYPE_SIZE, PORT, 

BAUD,DATA_BIT,STOP_BIT: INTEGER; 

PARITY : CHARACTER; 

— get parameters to establish serial connection 
procedure GET_AUV_PARAMETERS is 

TIME_ZONE_INFO, RECEIVER_INTERVAL_INFO, LINE : STRING(1..80); 
ZONE_INFO_SIZE, INTERVAL_SIZE,SIZE : INTEGER; 

INF ; TEXT_IO.FILE_TYPE; 
begin 

OPEN(INF, MODE => IN_FILE, NAME => "AUVSETUP.DAT"); 

GET_LINE(INF, LINE, SIZE); 

PORT := INTEGER'VALUE(LINE(1..SIZE)); 

GET_LINE(INF, LINE, SIZE); 

BAUD := INTEGER'VALUE(LINE(1..SIZE)); 

GET_LINE(INF, LINE, SIZE); 

DATA_BIT := INTEGER'VALUE(LINE(1..SIZE)); 

GET_LINE(INF, LINE, SIZE); 

PARITY := LINE{1); 

GET_LINE(INF, LINE, SIZE); 

STOP_BIT ;= INTEGER'VALUE(LINE(1..SIZE)); 

CLOSE(INF); 

end get_AUV_Parameters; 
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procedure init_Process_AUV_data is 
begin 

get_AUV_Paraineters; 

— establish a serial connection 

— and begin processing raw data 
open_serial(port,baud,data_bit,parity,stop_bit); 

end init Process AUV data; 


procedure SHUTDOWN_Process_AUV_Data is 
begin 

close_serial; 

end SHUTDOWN_Process_AUV_Data; 

procedure Process_AUV_Data{UPDAT£_REQUESTED : in out BOOLEAN) 

UNS_BYTE_INT : UNS8; 

FLAG : character; 
begin 
loop 

READ_CHAR(UNS_ByTE_INT, FLAG); 
exit when FLAG = 'Y'; 
end loop; 

UPDATE_REQUESTED ;= TRUE; 

exception 

when others => 

UPDATE_REQUESTED ;= FALSE; 

end PROCESS_AUV_DATA; 


end P_AUV; 
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File Name : P_GPS.A 

Author ; Se-Hung Kwak 

DATE : 9/11/91 

MODIFIED ; Lcdr C. D. Stevens 

DATE : 10/08/92 

COMMENTS : Init_Proce3s_GPS reads a setup file for 
parameters to initialize a serial port 
{RS-232) connection in this version, actual 
data is read from a file 

— Shutdown_Process_GPS terminates the serial 

connection 

Process_GPS_Data calls a procedure to 

initialize the proper receiver type and begin 
processing 

__★**★*★★****★********★*************★***•*★******★****★*********** 

with NAV_DATA, TEXT_IO, MOTOROLA; 
use NAV_DATA, TEXT_IO, MOTOROLA; 
package P_GPS is 

procedure init_Process_GPS_Data; 

procedure SHUTDOWN_Process_GPS_Data; 

procedure ProcGSS_GPS_Data(GPS_DATA : in out NAV_DATA_TYPE; 

END_DATA ; in out BOOLEAN; 

GPS_FILE ; in out ByTE_FILE.FILE_TyPE); 

end P_GPS; 

— serial is an assembly language program which buffers 

— serial stream data 

with SERIAL, MOTOROLA, TEXT_IO, NAV_DATA; 
use SERIAL, MOTOROLA, TEXT_IO, NAV_DATA; 

package body P_GPS is 

GPS_RECEIVER_TyPE : STRING(1..80); 

LOCAL_TIME_DIFF, RECEIVER_TyPE_SIZE, PORT, 

BAUD,DATA_BIT,STOP_BIT; INTEGER; 

PARITY ; CHARACTER; 

— get parameters to establish serial connection 
procedure GET_GPS_PARAMETERS is 

TIME_ZONE_INFO, RECEIVER_INTERVAL_INFO, LINE ; STRING(1..80); 
ZONE_INFO_SIZE, INTERVAL_SIZE,SIZE : INTEGER; 

INF : TEXT 10.FILE TYPE; 
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begin 

OPEN(INF, MODE => IN_FILE, NAME => "SETUP.DAT"); 
GET_LINE(INF, GPS_RECEIVER_TYPE, RECEIVER_TYPE_SIZE); 
GET_LINE(INF, LINE, SIZE); 

PORT := INTEGER'VALUE(LINE(1..SIZE)); 

GET_LINE(INF, LINE, SIZE); 

BAUD := INTEGER'VALUE(LINE(1..SIZE)) ; 

GET_LINE(INF, LINE, SIZE); 

DATA_BIT := INTEGER'VALUE(LINE{1..SIZE)) ; 

GET_LINE(INF, LINE, SIZE); 

PARITY := LINE(1); 

GET_LINE(INF, LINE, SIZE); 

STOP_BIT := INTEGER'VALUE(LINE(1..SIZE)); 

— time zone is not used in sans 
GET_LINE(INF, TIME_ZONE_INFO, ZONE_INFO_SIZE); 
LOCAL_TIME_DIFF := 

INTEGER'VALUE(TIME_ZONE_INFO(1..ZONE_INFO_SIZE)); 
CLOSE(INF); 

end get_GPS_Parameters; 


procedure init_Process_GPS_data is 
begin 

get_GPS_Parameters; 

— establish a serial connection 

— and begin processing raw data 

open_serial{port,baud,data_bit , parity,stop_bit); 
end init Process GPS_data; 


procedure SHUTDOWN_Process_GPS_Data is 
begin 

close_serial; 

end SHUTDOWN_Process_GPS Data; 


procedure Process_GPS_DATA(GPS_DATA ; in out NAV_DATA_TYPE; 

END_DATA : in out BOOLEAN; 

GPS_FILE ; in out BYTE_FILE.FILE_TYPE) is 

begin 

GET_MOTOROLA_DATA(GPS_FILE, GPS_DATA, END_DATA); 
exception 

when others => 
put_line("end3”); 

END_DATA := TRUE; 
end Process_GPS_DATA; 

end P_GPS; 
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Title ; Motorola.a 
Author : Lcdr C. D. Stevens 
DATE ; 9/11/91 

Comments : GET_MOTOROLA_DATA records variable length 

strings of Motorola Proprietary Binary Data. 

It is linked with package SANS. 
POST_PROCESS_MOTOROLA_DATA processes position 
format binary messages from an input file 
GPS.DAT and records them in a file OUTPUT.DAT. 
It is linked with package 
MOTOROLA_POST_PROCESSOR. 

Package Serial declares a type UNS8 which is a 
byte_integer in the range 0..255 to be 
compatible with Motorola binary format 
a problem exists in CHECK_SUM 

with TEXT_IO, NAV_DATA, SERIAL, SEQUENTIAL_IO; 

use NAV_DATA, SERIAL; 

package MOTOROLA is 

package BYTE_FILE is new SEQUENTIAL_IO(UNS8); 
use BYTE_FILE; 

— procedure records data to a file for post-processing 
procedure GET_MOTOROLA_DATA(GPS_FILE ; in out 

BYTE_FILE.FILE_TYPE; 

GPS_DATA: out NAV_DATA_TYPE; 

END_of_DATA :out BOOLEAN); 

— procedure reads a file and performs conversions 
procedure POST_PROCESS_MOTOROLA_DATA(TEST_FILE: in out 

BYTE_FILE.FILE_TYPE; 

OUTPUT_F.LE; in out TEXT_IO.FILE_TYPE; 

GPS_DATA: in out NAV_DATA_TYPE; 

END_DATA ; in out BOOLEAN); 


end MOTOROLA; 

with text_io, SERIAL, MATH_LIB, BIT_OPS; 
use text_io, SERIAL, MATH_LIB, BIT_OPS; 

package body MOTOROLA is 

package INTEGER_INOUT is new INTEGER_IO(INTEGER); 
package LONG_INTEGER_INOUT is new INTEGER_IO(LONG_INTEGER); 
package UNS_BYTE_INTEGER_INOUT is new INTEGER_IO(UNS8); 
package BYTE_INTEGER_INOUT is new INTEGER_IO(byte_integer); 
package FLOAT_INOUT is new FLOAT_IO(FLOAT); 

use INTEGER_INOUT, UNS_BYTE_INTEGER_INOUT, ByTE_INTEGER_INOUT, 
FLOAT_INOUT, LONG INTEGER INOUT; 
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— Motorola's start frame chars are '§§' 

— end frame chars are 'Cr' and 'Lf' 

FLAG : character; 
temp ; float; 

procedure GET_MOTOROLA_DATA(GPS_FILE : in out 

ByTE_FILE.FILE_TYPE; 
GPS_DATA: out NAV_DATA_TYPE; 

END_OF_DATA : out BOOLEAN) is 

UNS_BYTE_INT ; UNS8; 
begin 
loop 

READ_CHAR(UNS_BYTE_INT, FLAG); 
exit when FLAG = 'N'; 

WRITE(GPS_FILE, UNS_BYTE_INT); 

— *★* display output for OBSERVATION PURPOSES ONLY *** 
PUT(UNS_BYTE_INT); 

end loop; 
exception 

when others => 

END_OF_DATA := TRUE; 

end GET MOTOROLA DATA; 


procedure POST_PROCESS_MOTOROLA_DATA(TEST_FILE: in out 

BYTE_FILE.FILE_TYPE; 
OUTPUT_FILE; in out TEXT_IO.FILE_TYPE; 
GPS_DATA; in out NAV_DATA_TYPE; 
END_DATA : in out BOOLEAN) is 

INT_LONG : LONG_INTEGER := 0; 

UNS_BYTE_INT : UNS8 := 0; 

CHECK_SUM : BYTE_INTEGER := 0; 

FIX_SECONDS : DURATION; 

COUNT, INT_PDOP : INTEGER := 0; 

POSIT_FORMAT ; BOOLEAN := FALSE; 

TEMP_TIME : FLOAT; 





function PROCESS_CHECK_SUM(UNS_BYTE_INT ; UNS8) 

return BYTE_INTEGER is 

begin 

if UNS_BYTE_INT < 128 then 

CHECK_SUM := CHECK_SUM XOR BYTE_INTEGER{UNS_BYTE_INT); 
else 

— remove MSB to bring UNS_BYTE_INT into range of byte 

— integer then two's complement the result of XOR to 

— account for MSB's effect 
if CHECK_SUM < 0 then 

CHECK_SUM := ((CHECK_SUM XOR 

BYTE_INTEGER(UNS_BYTE_INT-128))+1)*(-1) 

else 

CHECK_SUM := (-1) * (CHECK_SUM XOR 

BYTE_INTEGER(UNS_BYTE_INT-12 8))-1; 

end if; 
end if; 

return CHECK_SUM; 
end PROCESS_CHECK_SUM; 

procedure PROCESS_LONG_INTEGER( 

INT_LONG ; in out LONG_INTEGER 

COUNT : in out INTEGER) is 

TWOS_COMPLEMENT : BOOLEAN := FALSE; 

BYTE_INT : BYTE_INTEGER; 

TEMP_LONG_INT : LONG_INTEGER; 

procedure GET_NEXT_BYTE is 
begin 

BYTE_FILE.READ{TEST_FILE, UNS_BYTE_INT); 

CHECK_SUM := PROCESS_CHECK_SUM{UNS_BYTE_INT); 

COUNT ;= COUNT + 1; 
if TWOS_COMPLEMENT then 

TEMP_LONG_INT ;= LONG_INTEGER(UNS_BYTE_INT) - 255; 
else 

TEMP_LONG_INT := LONG_INTEGER(UNS_BYTE_INT); 
end if; 

end GET_NEXT_BYTE; 
begin 

if UNS_BYTE_INT > 127 then 

TEMP_LONG_INT ;= LONG_INTEGER(UNS_BYTE_INT) - 256; 
TWOS_COMPLEMENT := TRUE; 
else 

TEMP_LONG_INT := LONG_INTEGER(UNS_BYTE_INT); 
TWOS_COMPLEMENT ;= FALSE; 
end if; 

INT_LONG := TEMP_LONG_INT * 2**24; 

GET_NEXT_BYTE; 

INT_LONG := INT_LONG + (TEMP_LONG_INT * 2**16); 
GET_NEXT_BYTE; 

INT_LONG := INT_LONG + (TEMP_LONG_INT * 2**8); 

GET NEXT_BYTE; 
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INT_LONG ;= INT_LONG + TEMP_LONG_INT; 
end PROCESS_LONG_INTEGER; 

procedure PROCESS_TIME(TEMP_TIME : in out FLOAT; 

COUNT : in out INTEGER) is 

begin 

TEMP_TIME := 0.0; 

BYTE_FILE.READ(TEST_FILE, UNS_BYTE_INT); 

CHECK_SUM ;= PROCESS_CHECK_SUM(uns_byte_int); 

TEMP_TIME := FLOAT(UNS_BYTE_INT) * 3600.0; 

COUNT := COUNT + 1; 

TEMP_TIME := TEMP_TIME + float(UNS_BYTE_INT) * 60.0; 
BYTE_FILE.READ(TEST_FILE, UNS_BYTE_INT); 

CHECK_SUM := PROCESS_CHECK_SUM(uns_byte_int); 

COUNT := COUNT + 1; 

TEMP_TIME ;= TEMP_TIME + float(UNS_BYTE_INT); 
PROCESS_LONG_INTEGER{INT_LONG, COUNT); 

TEMP_TIME := TEMP_TIME + float(INT_LONG) * (10.0 ** (-9)); 
PUT{OUTPUT_FILE, ' *); 

PUT(OUTPUT_FILE, TEMP_TIME, fore => 8, aft => 2, exp => 0) 
PUT(OUTPUT_FILE, ' '); 

end PROCESS_TIME; 

procedure PROCESS_VELOCITY( 

COUNT : in out INTEGER) is 

VEL, VEL_N, VEL_E, HDG, RADIANS : float ;= 0.0; 
begin 

VEL ;= FLOAT(UNS_BYTE_INT) * FLOAT(2 ** 8); 

BYTE_FILE.READ(TEST_FILE, UNS_BYTE_INT); 

CHECK_SUM := PROCESS_CHECK_SUM(uns_byte_int); 

COUNT ;= COUNT + 1; 

vel := (vel + float(uns_byte_int))/lOO.O; 

BYTE_FILE.READ(TEST_FILE, UNS_BYTE_INT); 

CHECK_SUM := PROCESS_CHECK_SUM(uns_byte_int); 

COUNT ;= COUNT + 1; 

HDG ;= FLOAT(UNS_BYTE_INT) * FLOAT(2 ** 8); 

BYTE_FILE.READ(TEST_FILE, UNS_BYTE_INT); 

CHECK_SUM ;= PROCESS_CHECK_SUM(uns_byte_int); 

COUNT := COUNT + 1; 

HDG := (HDG + float(uns_byte_int))/10.0; 

RADIANS ;= HDG/57.2958; 

VEL_N := COS(RADIANS) * VEL; 

VEL_E := SIN(RADIANS) * VEL; 

put(output_file, vel_n, fore => 5, aft => 2, exp => 0); 
PUT(OUTPUT_FILE, ' '); 

put(output_file, vel_e, fore => 5, aft => 2 , exp => 0); 
PUT(OUTPUT_FILE, ' '); 

put(output_file, hdg, fore => 5, aft => 2, exp => 0); 
PUT(OUTPUT_FILE, ' '); 

put(output_file, vel, fore => 5, aft => 2, exp => 0); 
PUT(OUTPUT_FILE, ' '); 

end PROCESS VELOCITY; 
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procedure PROCESS_PDOP( 

COUNT : in out INTEGER) is 

POOP ; float := 0.0; 
begin 

GPS_DATA.PDOP ;= INTEGER(UNS_BYTE_INT) * (2**8); 

POOP := FLOAT(UNS_BYTE_INT) * FLOAT(2 ** 8); 

BYTE_FILE.READ(TEST_FILE, UNS_BYTE_INT); 

CHECK_SUM := PROCESS_CHECK_SUM(uns_byte_int); 

PDOP ;= (PDOP + float(UNS_BYTE_INT))/10.0; 
PUT(OUTPUT_FILE, PDOP, fore => 4, aft => 0, exp => 0); 
GPS_DATA.PDOP := (GPS_DATA.PDOP + 

INTEGER{UNS_BYTE_INT))/10; 

COUNT := COUNT + 1; 
end PROCESS_PDOP; 

procedure SYNCH_WITH_HEADER is 

FIRST_DELIMITER : BOOLEAN := FALSE; 
begin 

— loop until ASCII character 0 is received (first 

— delimiter) 
loop 

BYTE_FILE.READ(TEST_FILE, UNS_BYTE_INT); 

PUT(OUTPUT_FILE, COUNT); 
exit when UNS_BYTE_INT = 64; 
end loop; 

BYTE_FILE.READ(TEST_FILE, UNS_BYTE_INT); 

PUT(OUTPUT_FILE, COUNT); 
if UNS_BYTE_INT =64 then 

BYTE_FILE.READ(TEST_FILE, UNS_BYTE_INT); 

PUT(OUTPUT_FILE, COUNT); 
if UNS_BYTE_INT =66 then 

BYTE_FILE.READ(TEST_FILE, UNS_BYTE_INT); 

PUT(OUTPUT_FILE, COUNT); 
if UNS_BYTE_INT = 97 then 
POSIT_FORMAT := TRUE; 

COUNT ;= 4; 

CHECK_SUM := 35; 
end if; 
end if; 
end if; 

end SYNCH WITH HEADER; 
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begin 

SYNCH_WITH_HEADER; 
loop 

BYTE_FILE.READ(TEST_FILE, UNS_BYTE_INT); 

COUNT ;= COUNT + 1; 

PUT{OUTPUT_FILE, COUNT); 

CHECK_SUM := PROCESS_CHECK_SUM{uns_byte_int); 

if POSIT_FORMAT then 
if count = 9 then 
— get time in seconds 
PROCESS_TIME(TEMP_TIME, COUNT); 

— get latitude 
elsif COUNT = 16 then 

PROCESS_LONG_INTEGER(INT_LONG, COUNT); 

temp := float(int_long)/(3.6 * (10.0 ** 6)); 

put(output_file, temp, fore => 6, aft => 6, exp => 0); 

PUT(OUTPUT_FILE, ' '); 

GPS_DATA.LATITUDE := NAV_CONVERSION{INT_LONG); 

— get longitude 
elsif COUNT = 20 then 

PROCESS_LONG_INTEGER(INT_LONG, COUNT); 
temp := float(int_long)/(3.6 * (10.0 ** 6)); 
put(output_file, (360.0 + temp), fore => 6, aft => 6, exp 
=> 0 ); 

put(output_file, ' '); 

GPS_DATA.LONGITUDE ;= NAV_CONVERSION(INT_LONG); 

— get ellipsoidal height 
elsif COUNT = 24 then 

PROCESS_LONG_INTEGER(INT_LONG, COUNT); 
temp ;= float(int_long)/(100.0); 

put(output_fiie, temp, fore => 6, aft => 2, exp => 0); 
PUT(OUTPUT_FILE, ' '); 

elsif COUNT = 32 then 

PROCESS_VELOCITY(COUNT); 

elsif COUNT = 36 then 
PROCESS_PDOP(COUNT); 

elsif COUNT = 65 then 

if CHECK_SUM = BYTE_INTEGER(UNS_BYTE_INT) then 
PUT(OUTPUT_FILE, " GOOD CHECKSUM"); 
else 

PUT(OUTPUT_FILE, " BAD CHECKSUM"); 
end if; 
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elsif UNS_BYTE_INT = 13 then 
— count is 65 vice 67 

BYTE_FILE.READ(TEST_FILE, UNS_BYTE_INT); 
COUNT := COUNT + 1; 
if UNS_BYTE_INT =10 then 
exit; 
end if; 
end if; 
end ?f ; 
end loop; 

new_line(output_file); 

—NAV DATA.PUT(GPS_DATA); 


exception 

when others => 
put_line("end of file"); 
END_DATA := TRUE; 
end POST_PROCESS_MOTOROLA_DATA; 

end MOTOROLA; 
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File Name : SERIAL_D.A 
Author : Se-Hung Kwak 
DATE ; 9/11/91 

Modified : Lcdr C. D. Stevens to include type UNS8 which 
is an unsigned byte integer in the range 
0..255 to be 

compatible with Motorola Proprietary Binary 
Format 




package SERIAL is 

— UNS8 is a subtype byte_integer (8-bit integer) 

— which is natural vice 2's complement 
type UNS8 is range 0..255; 

— procedure READ_CHAR(CH, DATA_READY : out CHARACTER); 

pragma INTERFACE(assembly, read_char); 

— function WRITE_CHAR(CH: in CHARACTER) return CHARACTER; 

pragma INTERFACE(assembly, write_char); 

procedure READ_CHAR(CH : out UNS8; 

DATA_READY : out CHARACTER); 
pragma INTERFACE(assembly, read_char); 

function WRITE_CHAR(CH: in CHARACTER) return UNS8; 
pragma INTERFACE(assembly, write_char); 

procedure OPEN_SERIAL(PORT, BAUD, DATA_BIT: INTEGER; 

PARITY:CHARACTER; STOP: INTEGER); 


procedure 

INIT_SERIAL(KA_REG,TX_REG,INT_EN,LINE_CRT,MODEM_CRT,LINE_STAT, 
BAUD_LSB,LINE,INT_MASK,INT_NUM: in INTEGER); 
pragma INTERFACE(assembly, init_serial); 


procedure CLOSE_SERIAL; 

pragma INTERFACE(assembly, close_serial); 


end SERIAL; 









File Name : SERIAL.A 
Author : Se-Hung Kwak 
DATE : 9/11/91 

******** ************** *1t ******* it * it * * it ******** -k ************** it * 


package body SERIAL is 


procedure OPEN_SERIAL(PORT, BAUD, DATA_BIT: INTEGER; 

PARITY-.CHARACTER; STOP; INTEGER) is 
OFFSET ; constant INTEGER 16#100#; 

RX_REG : INTEGER := 16#2F8#; 

TX_REG ; INTEGER := 16#2F8#; 

INT_EN ; INTEGER := 16#2F9#; 

LINE_CRT : INTEGER := 16#2FB#; 

MODEM_CRT : INTEGER := 16#2FC#; 

LINE_STAT : INTEGER := 16#2FD#; 

BAUD_LSB, LINE, INT_MASK, INT_NUM : INTEGER; 
begin 

if PORT = 1 then 

RX_REG ;= RX_REG + OFFSET; 

TX_REG ;= TX_REG + OFFSET; 

INT_EN ;= INT_EN + OFFSET; 

LINE_CRT ;= LINE_CRT + OFFSET; 

MODEM_CRT := MODEM_CRT + OFFSET; 

LINE_STAT := LINE_STAT + OFFSET; 
end if; — default port2 


if BAUD = 1200 then 
BAUD_LSB ;= 96; 
elsif BAUD = 2400 then 
BAUD_LSB := 48; 
elsif BAUD = 4800 then 
BAUD_LSB := 24; 
else 

BAUD_LSB ;= 12; 
end if; 


default port2 


if DATA_BIT = 5 then 
LINE ;= 0; 

elsif DATA_BIT = 6 then 
LINE ;= 1; 

elsif DATA_BIT = 7 then 
LINE := 2; 
else 

LINE := 3; — default 8 data bits 

end if; 
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if STOP = 2 then 

LINE ;= LINE + 16#4#; 
end if; 

if /= 'N' then 

LINE := LINE + 16#8#; 
if PARITY = 'E' then 
LINE := LINE + 16#10#; 
end if; 
end if; 

if PORT = 1 then 

INT_MASK := 16#EF#; 
else 

INT_MASK ;= 16#F7#; 

3 

end if; 

if PORT = 1 then 
INT_NUM := 16#0C#; 

( 12 ) 

else 

INT_NUM ;= 16#0B#; 

( 11 ) 

end if; 


— default 1 stop bit 

— default parity : odd 

-- reset bit 4 

— default port2 & reset bit 

— SERIAL 1 INTERRUPT #, OCH 

— default SERIAL2 INT #, OBH 


INIT_SERIAL(RX_REG,TX_REG,INT_EN,LINE_CRT,MODEM_CRT,LINE_STAT, 
BAUD_LSB,LINE,INT_MASK,INT_NUM); 

end OPEN_SERIAL; 

end SERIAL; 

t 

; File Name : SERIAL.ASM 
; Author : Se-Hung Kwak 

; DATE ; 9/11/91 

; Modified : Lcdr C. D. Stevens to eliminate the stripping of 
; bit 7 from ASCII characters since Motorola 

; proprietary binary format uses all 8 bits 

t 
t 

NAME SERIAL 
DGROUP GROUP DATA 

data segment para public 'data' 
bufsiz equ 4096 

buffer db bufsiz dup(O) 

bufptrl dw 0 


; buffer 

; points to start of 
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buffer 



bafptr2 dw 

0 

points to end of buffer 

bufcs dw 

0 

interrupt vector cs 

buffer 



bufip dw 

0 

interrupt vector ip 

buffer 



RX REG DW 

0 

RX REG ADDRESS 

TX REG DW 

0 

TX REG ADDRESS 

INT EN DW 

0 

INT ENABLE REG ADDRESS 

LINE CRT DW 

0 

LINE CRT REG ADDRESS 

MODEM CRT DW 

0 

MODEM CRT REG ADDRESS 

LINE STAT DW 

0 

LINE STAT REG ADDRESS 

BAUD LSB DW 

0 

BAUD DIVISOR (LSB) 

LINE DW 

0 

LINE VALUE (DATA 

BIT,PARITY,STOP) 



INT MASK DW 

0 

8259 INT MASK VALUE FOR 

PORTl OR 2 



INT NUM DW 

0 

INTERRUPT NUMBER FOR 

PORTl OR 2 



data ends 




/ 


SERIAL segment para public 'code' 
ASSUME CS: SERIAL, DS:DGROUP 


f 

• 

; Procedure INIT_SERIAL(RX_REG,TX_REG,INT_EN,LINE_CRT,MODEM_CRT, 
; LINE_STAT,BAUD_LSB,LINE,INIT_MASK, 

; INT_NUM ; in INTEGER); 

/ 

/ 

★ ♦ ★ ★ ^ ★ 


PUBLIC INIT SERIAL 














INIT_SERIAL 

PROC FAR 


cli 


;disable all interrupts 

PUSH 

BP 


MOV 

BP, SP 


PUSH 

DS 


MOV 

AX, DATA 


MOV 

DS, AX 


PUSH 

DX 


PUSH 

DI 


PUSH 

SI 


PUSH 

CX 


mov 

ax, [BP+6] 

; GET RX REG ADDR 

mov 

RX REG, ax 


mov 

ax, [BP+8] 

; GET TX REG ADDR 

mov 

TX REG, ax 


mov 

ax, [BP+10] 

; GET INT EN ADDR 

mov 

INT EN, ax 


mov 

ax, [BP+12] 

; GET LINE CRT ADDR 

mov 

LINE CRT, ax 


mov 

ax, [BP+14] 

; GET MODEM CRT ADDR 

mov 

MODEM CRT, ax 


mov 

ax, [BP+16] 

; GET LINE STAT ADDR 

mov 

LINE STAT,ax 


mov 

ax, [BP+18] 

; GET BAUD LSB 

mov 

BAUD LSB,ax 


mov 

ax, [BP+20] 

; GET LINE 

mov 

LINE, ax 


mov 

ax, [BP+22] 

; GET INT MASK 

mov 

INT MASK, ax 


mov 

ax, [BP+24] 

; GET INT NUM 

mov 

INT_NUM, ax 


$ 

; set baud 



t 

mov 

dx, LINE CRT 

; select baud divisor 

mov 

ax, dx 


mov 

al, 80h 


out 

dx, al 


mov 

dx, RX REG 

; LSB divisor 

mov 

ax, BAUD LSB 


out 

dx, al 


mov 

dx, INT EN 

; MSB divisor 

mov 

al, 0 


out 

dx, al 


f 

; init line 

control reg. 


r 

mov 

dx, LINE CRT 


mov 

ax, LINE 


out 

dx, al 
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init modem control reg 


mov 

dx, 

MODEM CRT 


mov 

al, 

OBh 

; loop back test 

out 

dx. 

al 


enable interrupts 


mov 

dx, INT EN 


mov 

al, 1 

; enabled receiver-data-ready 

out 

dx, al 


f 

; save interrupt vector 

• 


9 

push 

es 

; es:bx vector will be returned 

push 

bx 


mov 

ax, INT NUM 

; give interrupt number 

mov 

ah, 35h 

; dos function call #35h: get vector 

int 

21h 

; dos function call int 21h 

mov 

bufip, bx 

; save ip 

mov 

bufcs, es 

; save cs 

pop 

bx 


pop 

es 


mov 

CX, INT_NUM 

; save INT_NUM into CX because of DS 

• 

1 

• 


change 

9 

; Set up 

interrupt vector 

table 

? 

push 

table 

ds 

; ds:dx will be saved into vector 

push 

dx 


mov 

ax, offset asyint 

mov 

dx, ax 


mov 

ax, cs 


mov 

ds, ax 


mov 

ax, CX 

; give interrupt number 

mov 

ah, 25h 

; dos function call #25h: Set int 
; vector 

int 

21h 

; dos function call int 21h 

pop 

dx 


pop 

ds 
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adjust interrupt mask reg in 8259 


in 

al, 

21h ; 

interrupt mask pattern 

and 

ax, 

INT_MASK ; 

enable irq3 or 4 by resetting 



• 

9 

proper bit 

out 

21h 

, al ; 

save to interrupt mask reg in 8259 

POP 

CX 



POP 

SI 



POP 

DI 



POP 

DX 



POP 

DS 



POP 

BP 



sti 




RET 

20 



INIT SERIAL 

ENDP 




******************.*.************************* 

f 

; Procedure 

CLOSE_SERIAL 


/ 

1 * 

PUBLIC 

CLOSE_ 

SERIAL 


CLOSE_SERIAL 

PROC 

FAR 


cli 


• 

t 

disable all interrupts 

PUSH 

DS 



MOV 

AX, 

DATA 


MOV 

DS, 

AX 


PUSH 

CX 



9 

; adjust interrupt 

• 

mask reg in 8259 

t 

push 

bx 



mov 

bx. 

INT_MASK ; 

get INT MASK pattern 

not 

bx 

9 

flip INT_MASK pattern 

mov 

ax. 

bx 


in 

al. 

21h 

interrupt mask pattern 

or 

ax. 

bx ; 

disable irq3 or 4 by setting 



9 

proper bit 

out 

21h 

, al ; 

save to interrupt mask reg in 8259 

pop 

bx 



MOV 

CX, 

INT_NUM ; 

save INT_NUM into CX because of DS 



9 

change 
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restore interrupt vector for serial-2 


push 

ds 


; ds:dx will be saved into vector 




; table 

push 

dx 



mov 

dx. 

buf ip 


mov 

ds, 

bufcs 


mov 

ax, 

CX 

; get proper INTERRUPT NUMBER 

mov 

ah. 

25h 

; dos function call #25h: Set int 




; vector 

int 

21h 


; dos function call int 21h 

pop 

ds 



pop 

dx 



POP 

CX 



POP 

DS 



sti 



; enable all interrupts 





SERIAL 

ENDP 




• 'kirititititieitit'kitir'kieifitiritieieititirifiritieitifieiriritirititititiritifit'kiriritiritirit'kit'kitirititir'kiritiricie 

• 

; Procedure READ_CHAR{CH, DATA_READY ; out CHARACTER); 

; DATA_READY = 'Y' New CH 

; DATA_READY = 'N' NO CH 

• kkiriFkrie'kie'kk'kieir'kiririririririt'kiriririritirif'kiririt'kie'kiritifkiririrk'kieifkitif'k'kiritkir'kitie'k-kitit'k 

PUBLIC READ_CHAR 
READ CHAR PROC FAR 


STI 




PUSH 

BP 



MOV 

BP, SP 



PUSH 

DS 



MOV 

AX, DATA 



MOV 

DS, AX 



call 

chget 



mov 

bx, ax 

• 

/ 

save received char 

mov 

al, ah 



PUSH 

ES 



LES 

SI, DWORD PTR 

[BP+10] 


MOV 

AL, 'N' 



MOV 

ES:[SI], AL 

• 

f 

DATA_READY = N 

CMP 

AH, 0 



JE 

R END 

• 

f 

NO Ch Available -> return 

LES 

SI, DWORD PTR 

[BP+10] 


MOV 

AL, 'Y' 



MOV 

ES:[SI], AL 

f 

YES, ch. DATA_READY = Y 

LES 

SI, DWORD PTR 

[BP+6] 


mov 

ax, bx 

• 

9 

restore received char 
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MOV 

ES; 

[SI], AL 

; Return CH 

R END; POP 


ES 


POP 

DS 



POP 

BP 



RET 

8 



READ CHAR 

ENDP 




9 

; Function 

WRITE CHAR(CH; in 

CHARACTER) return CHARACTER 

• 

9 


Return 

'Y' CH is out 

• 

9 


Return 

'N' CH is not out. Buffer is full 


PUBLIC 

WRITE 

CHAR 


WRITE CHAR 

PROC 

FAR 


STI 




PUSH 

BP 



MOV 

BP, 

SP 


PUSH 

DS 


; Save DS 

MOV 

AX, 

DATA 

; Data is accessable 

MOV 

DS, 

AX 


MOV 

CL, 

'N' 

; TX buf is full 

MOV 

DX, 

LINE STAT 

; Line Status Reg 

IN 

AL, 

DX 


TEST 

AL, 

20H 

; TX is empty? 

JZ 

W END 

; Not empty, return 

MOV 

AL, 

[BP+6] 

; Get CHAR 

MOV 

DX, 

TX REG 

; Output to TX Reg 

OUT 

DX, 

AL 


MOV 

CL, 

'Y' 

; Success 

W END; 




POP 

DS 



POP 

BP 



RET 

2 



WRITE CHAR 

ENDP 




serial communication interrupt routine 


asyint proc far 
push dx 

push bx 

push ax 
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; place the ascii char into the buffer. 

'■ CU 

push ds 

mov ax, data 

mov ds, ax 

mov dx, RX_REG ; read data port 

in ai,dx 

; DO NOT strip bit 7 for Motorola unsigned byte integer 


operations 

; and 

al,7fh 

mov 

bx,bufptr2 

mov 

(buffer+bx], 

inc 

bx 

cmp 

bx,bufsi 2 

jc 

asyskip 

mov 

bx, 0 

asyskip: cmp 

bx,bufptrl 

jz 

end_asy 

mov 

bufptr2,bx 

J 

end asy; mov 

al,20h 

interrupt) command 

out 

20h,al 

reg) 

pop 

ds 

sti 

pop 

ax 

pop 

bx 

pop 

dx 

iret 


asyint endp 


; strip off bit 7 
; bx <- bufptr2 
; save into buffer 
; inc ptr2 
; end of buffer ? 

; no 

; yes, wrap around 
; buffer full ? 

; yes, ignore input data 
; save ptr2 into bufptr2 

; send EOI (end of 

; to port 20 (8259 command 


crt character (al <- data, ah <- 1 ; success, ah <- 0 : buffer 


emp^> ) 



f 

chget proc 

near 


push 

bx 


; cli 


; disable all interrputs 

mov 

bx,bufptrl 

; get ptrl 

cmp 

bx,bufptr2 

; buffer empty ? 

jnz 

chget2 

• 

t 

mov 

ah, 0 

; no char in the buffer 

jmp 

chgete 

; get out from chget 

7 

chget2: mov 

al,[buffor+bx] 

; NO, pass char through 



; al reg 

inc 

bx 

; inc ptrl 

cmp 

bx, bufsiz 

; end of buffer ? 
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jc 

chgetS 

7 

mov 

bx, 0 

; YES, reset ptrl 

chget3; mov 

bufptrl,bx 

; save ptrl 

mov 

ah, 1 

; success 

chgete; 



; sti 


; enable int 

pop 

bx 


ret 




chget endp 


display a char on the screen in the al reg with ascii format 


disply proc near 

push bx 

push ax ; save char 


; prepare to display the char. 

mov bx , 0 

mov ah,14 

int lOh 

pop ax 

push ax 

cmp al,Odh 

jn 2 end_dis 

t 

; return -> return + line feed 

f 

mov al,Oah 

mov bx, 0 

mov ah,14 

int lOh 

end_dis: pop ax 

pop bx 

ret 

disply endp 


SERIAL ends 
end 
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File Name : ANALOG.A 

Author : Lcdr C. D. Stevens 

Date : 01 December 1992 

Comments : A_to_D is a package which controls the operation 
of the Sapphire A to D converter through I/O 
reads and writes 

procedures are provided to read the ports from a 
setup file and eventually the base address 


with TEXT_IO, CALENDAR; 
use TEXT_IO, CALENDAR; 
package A_to_D is 

procedure A_TO_D_PARAMETERS(HDG_PORT, DEPTH_PORT : out 

INTEGER); 

procedure CURRENT_DIGITAL_VALUE(PORT : in INTEGER; 

FIX_TIME : in out TIME; 

OUTPUT : in out INTEGER); 

function CURRENT_HEADING(DATA : INTEGER) return INTEGER; 
function CURRENT_DEPTH(DATA : INTEGER) return INTEGER; 
end A to_D; 
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with PORT, SPIO, TEXT_IO, CALENDAR, SYSTEM; 
use PORT, SPIO, TEXT_IO, CALENDAR; 
package body A_to_D is 

package INTEGER_INOUT is new INTEGER_IO(INTEGER); 
package FLOAT_INOUT is new FLOAT_IO(FLOAT); 
use INTEGER_INOUT; 
use FLOAT_INOUT; 

procedure A_TO_D_PARAMETERS(HDG_PORT, DEPTH_PORT rout INTEGER) 

is 

INFO : FILE_TYPE; 

LINE : STRING(1..5); 

SIZE : INTEGER; 
begin 

— open the setup file and read ports for depth and heading 

— analog inputs (adjustable base address may be implemented 
— later) 

OPEN(INFO, MODE => IN_FILE, NAME => "A_TO_D.dat"); 
GET_LINE(INFO, LINE, SIZE); 

HDG_PORT ;= INTEGER'VALUE(LINE(1..SIZE)) ; 

GET_LINE(INFO, LINE, SIZE); 

DEPTH_PORT := INTEGER'VALUE(LINE(1..SIZE)) ; 

— BASE_ADDR := INTEGER'VALUE(LINE(1..SIZE)); 

CLOSE(INFO); 
end A_TO_D_PARAMETERS; 

procedure CURRENT_DIGITAL_VALUE(PORT : in INTEGER; 

FIX_TIME : in out TIME; 

OUTPUT : in out INTEGER) is 

IN_4LSB : INTEGER := 16#300#; — Input 4 Least 

—Significant Bits 
— Base 300 + Offset 0 

TRIGGER ; INTEGER ;= 16#301#; — 12 Bit A to D 

— Trigger(Output) 

IN_8MSB : INTEGER := 16#301#; — Input 8 MSB's 

— Base 300 + Offset 1 

CONTROL_REGl ; INTEGER := 16#302#; — Control Register 1 
STATUS_REG ; INTEGER := 16#302#; — A to D Conversion Status 

— Register (In) 

— Base 300 + Offset 2 

CONTROL_REG2 : INTEGER := 16#303#; — Control Register 2 

— Base 300 + offset 3 

VOLT_RNG : INTEGER := 16#10#; — Write to Control 

— Register 2 

— Analog Input Range 0-10 volts 
DATA_LSB, DATA_MSB, LOOPS : INTEGER := 0; 

procedure CONVERSION_STATUS is 
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STATUS_VAL : INTEGER; 

CONVERSION_COMPLETE : BOOLEAN := FALSE; 
begin 

check the status register until A to D conversion 

— complete 

— bit 7=0 indicates conversion complete 
loop 

STATUS_VAL ;= IN_BYTE(STATUS_REG); 

— Hex 80 = 1000 0000 and STATUS_VAL is binary 
if STATUS_VAL < 16#80# then 
CONVERSION_COMPLETE := TRUE; 
end if; 

exit when CONVERSION__COMPLETE; 
end loop; 

end CONVERSION STATUS; 


no 





begin 

OUT_BYTE(C0NTR0L_REG2, VOLT_RNG); 
OUT_BYTE(CONTROL_REG1, PORT); 
delay 0.001; 

OUT_BYTE(TRIGGER, 1); 


— write voltage range 

— Select Mux Channel 

— wait for new channel to 

— settle 

— Trigger Conversion 


— check status register and wait until conversion complete 
CONVERSION STATUS; 


DATA_LSB ;= IN_BYTE(IN_4LSB); — Read LSB's 

DATA_MSB ;= IN_BYTE(IN_8MSB); — Read MSB's 


— extract 12-bit integer from the two-byte code 
OUTPUT ;= (DATA_LSB/16) + (DATA_MSB * 16); 
end CURRENT DIGITAL VALUE; 


— Convert the A to D output to a compass heading in degrees 

— 0.1 volts = 000 degrees 

— 1.9 volts = 360 degrees 

function CURRENT_HEADING(DATA : INTEGER) return INTEGER is 
VOLTS, HEADING : FLOAT; 
begin 

VOLTS ;= ((FLOAT(DATA) * 10.0)/4096.0 ) ; 

HEADING ;= (VOLTS - 0.1) * 200.0; 
return INTEGER(HEADING); 
end CURRENT HEADING; 


— Convert the A to D digital output to actual depth 

— 1.0 volts = 0 Feet 

— 6.0 volts = 220 Feet (0 32 feet per atmosphere) 

— 0 - 100 PSIS (6.8 Atmospheres) 

function CURRENT_DEPTH(DATA ; INTEGER) return INTEGER is 
VOLTS, DEPTH : FLOAT; 
begin 

VOLTS := (FLOAT(DATA) * 10.0)/4096.0; 

—convert to meters 9.85 meters/atmosphere 
DEPTH := (VOLTS - 1.0) * 9.85 * 6.8/5.0; 
return INTEGER(DEPTH); 
end CURRENT_DEPTH; 


end A_to_D; 
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Title : gyro_cnt.a 

Author ; Se-Hung Kwak, Lcdr C. D. Stevens 

DATE : 2/20/93 

Comments : Gryo_cnt.a provides the Pragma Interface with 

assembly language Gyro_cnt.asm 


package GYR0_CNT is 

procedure INIT_DIGITAL_COUNTER; 

pragma INTERFACE (assembly, INIT_DIGITAL_COUNTER); 

function READ_PITCH return integer; 

pragma INTERFACE (assembly, READ_PITCH); 

procedure RESTORE_INTERRUPTS; 

pragma INTERFACE (assembly, RESTORE_INTERRUPTS); 

procedure SAPPHIRE_DELAY; 

pragma INTERFACE (assembly, SAPPHIRE_DELAY); 

end GYRO CNT; 
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File Name : GYROCNT.ASM 

Authors : Se-Hung Kwak, LCDR C. D. STEVENS 

DATE : 2/20/93 

Comments ; Implements an assembly language driver for a 

Gyration, Inc. miniature spin gyroscope 
The service is interrupt driven through LPTl 

interfaced through a Sapphire A to D converter 

NAME GYR0_CNT 
DGROUP GROUP DATA 


data segment para public 'data' 
; PITCH CALC variables 


old_data 

db 

0 

; previous 

state value 

old hi 

db 

0 

; previous 

hi_bit value 

old_lo 

db 

0 

; previous 

lo_bit value 

count 

dw 

0 



buf ip 

dw 

0 



bufcs 

dw 

0 



buf im 

dw 

0 




; INTERRUPT INITIALIZATION variables 

INT_MASK DW 0 ; 8259 INT MASK VALUE FOR 

PORTl OR 2 

INT_NUM DW 0 ; INTERRUPT NUMBER FOR 

PORTl OR 2 

data ends 

* 

f 

CODE segment para public 'code' 

ASSUME CS:CODE, DS;DATA 

• *★*★★*★**★★★★★****★★★★★★♦★♦■*■*★★***♦♦**♦■*■★★★★★*♦★**★★**★★♦**■ 
t 

; Procedure INIT_DIGITAL_COUNTER 

t 

• 'k-k-kirifk-k'kifk'k-kitieirifiririnr'kit'kifiFir-iiirfeiririilr'kiriririfk-kit’tr'kir'k’kirltitir’k’k'k'k'k'kititit'k 

PUBLIC INIT_DIGITAL_COUNTER 

INIT_DIGITAL_COUNTER PROC FAR 
/ 

cli ;disable all interrupts 

PUSH BP 

MOV BP, SP 

PUSH DS 

MOV AX, DATA 

MOV DS, AX 
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PUSH 

DX 



PUSH 

DI 



PUSH 

SI 



PUSH 

CX 



mov 

iNT_MASK, 07fh ; 8259 interrupt mask pattern 

mov 

INT_NUM, Ofh 

; interrupt number for LPTl 

program 

sapphire board 



push 

ax 



push 

dx 



mov 

dx,0302h 



mov 

al,08 



out 

dx,al 7 

output port #302h 1000 (8h) 

pop 

dx 



pop 

ax 



set counter initial value 



mov 

ax, 0 



mov 

count,ax 



save interrupt vector 



push 

es 

• 

f 

es;bx vector will be returned 

push 

bx 



mov 

ax, INT NUM 

t 

give interrupt number 

mov 

ah, 35h 

• 

9 

dos function call #35h: get vector 

int 

21h 

• 

9 

dos function call int 21h 

mov 

bufip, bx 

• 

9 

save ip 

mov 

bufcs, es 

9 

save cs 

pop 

bx 



pop 

es 



mov 

CX, INT_NUM 

• 

9 

save INT_NUM into CX because of DS 



• 

9 

change 

Set up 

interrupt vector 

table 

push 

ds 

/ 

ds:dx will be saved into vector 



? 

table 

push 

dx 



mov 

ax, offset 

PITCH CALC 

mov 

dx, ax 



mov 

ax, cs 



mov 

ds, ax 



mov 

ax, CX 

9 

give interrupt number 

mov 

ah, 25h 

9 

dos function call #25h: Set int 



9 

vector 


; dos function call int 21h 


int 

pop 

pop 


21h 

dx 

ds 
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• 

9 

; adjust 

• 

interrupt mask reg 

in 8259 

9 

in 

al, 21h 

; interrupt mask pattern 

mov 

bufim,ax 

; save interrupt mask for 
; restoration 

and 

ax, INT MASK 

; enable irqS by resetting properbit 

out 

21h, al 

; save to interrupt mask reg in 8259 

POP 

CX 


POP 

SI 


POP 

DI 


POP 

DX 


POP 

DS 


POP 

BP 


sti 



RET 



INIT DIGITAL COUNTER ENDP 


• 

9 

.******************. 



; function READ_PITCH return INTEGER; 

• 

PUBLIC READ_PITCH 
read_pitch proc far 

9 

sti 

push ds 

mov ax,data 

mov ds,ax 

mov cx,count ; recall current pitch_count 

pop ds 

ret 

read_pitch endp 
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PITCH_CALC interrupt service routine 


1 

PUBLIC 

PITCH CALC 


PITCH CALC PROC FAR 


CLI 

PUSH 

DX ; 

save register contents 

PUSH 

AX 


PUSH 

DS ; 

make data segment visible 

MOV 

AX,DATA 


MOV 

DS,AX 


; read status 

register and evaluate state changes 

mov 

dx,0302h 


in 

al ,dx 

; input al register contents of 

status register 

mov 

ah, al 


; and 

ah,07h 

not needed but may affect 

output pattern 

• 

9 


0P4 thru OPl 

and 

al,30h 

; extract bits 5 and 6 

cmp 

al,30h 

; test new case for state 11 

jne 

update 

; no other case matters 

mov 

dl,old_data 

; recall last state for comparisons 

cmp 

dl,10h 

; check for cw rotation 

jne 

ccw 


inc 

count 


jmp 

update 


ccw; cmp 

dl,20h 

; check for ccw rotation 

jne 

update 


dec 

count 


update: mov 

old_data, 

al ; update previous state value in 

; data 

MOV 

AL,20H 

; send EOI (end of interrupt) 

; command 

OUT 

20H,AL 

; to port 20 (IBM specific - 8259 
; register) 

mov 

dx,302h 

; reset int 
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mov 

al,ah 


or 

al,08h 


out 

dx, al 


POP 

DS 

; restore data segment 

POP 

AX 

; restore registers 

POP 

DX 


STI 



I RET 


; return control to BP 


(previous routine) 

; (interrupt return) 

PITCH CALC ENDP 


I 

; procedure RESTORE_INTERRUPTS (termination routine) 

t 

PUBLIC RESTORE_INTERRUPTS 
restore_interrupts proc far 


cli 



push 

dx 

; save registers 

push 

ds 


mov 

ax,data 

; make data visible 

mov 

ds,ax 


mov 

ax,bufim 

; recall interrupt mask 

out 

21h, al 

; restore to interrupt mask reg 

mov 

dx,bufip 

; recall initial interrupt vector 

mov 

ax,bufcs 


mov 

ds, ax 


mov 

ax,Ofh 

; load interrupt level 

mov 

ah, 25h 

; dos function call #25h: Set int 



; vector 

int 

21h 

; dos function call int 21h 

pop 

ds 

; restore registers 

pop 

dx 


sti 



ret 




restore_interrupts endp 
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Debugging routine 

display a char on the screen in the al reg with ascii format 
example ; 

mov ax,[some register] 

call disply 


disply proc 
push 
push 


near 

bx 

ax 


save char 


r 

; prepare to 

• 

display the char. 

9 

mov 

bx, 0 

mov 

ah, 14 

int 

lOh 

pop 

ax 

push 

ax 

cmp 

al,0dh 

jnz 

end_dis 

; return -> 

return + line feed 

mov 

al,Oah 

mov 

bx, 0 

mov 

ah, 14 

int 

lOh 

end_dis:pop 

ax 

pop 

bx 

ret 


disply endp 

• 


9 

CODE ends 


end 
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File Name : NAV.A 

Author : Lcdr C.D. Stevens 

Date : 12-3-92 

Comments : Nav_Data provides the declarations for a 

navigation data type 

function nav conversion converts 


a long_integer input to a type degree type 
Put outputs a nav_data_type 

_ **•********★**★*★★★*****★*****♦*★**•***★★★★**************★**** 


with CALENDAR; use CALENDAR; 
package NAV_DATA is 

type DEGREE_TYPE is 
record 

DEGREES : INTEGER; 

MINUTES : INTEGER; 

SECONDS : FLOAT; 
end record; 

type NAV_DATA_TYPE is 
record 

FIX_TIME : TIME; 

LATITUDE : DEGREE_TYPE; 

LONGITUDE ; DEGREE_TYPE; 

DEPTH : FLOAT; 

PDOP ; INTEGER; 

end record; 

— Data type to track AUV's ascent vector 

type DELTA_TYPE is 
record 

DELTA_LAT ; FLOAT; 

DELTA_LONG ; FLOAT; 
end record; 

function NAV_CONVERSION(VAR : LONG_INTEGER; 

DATA : DEGREE_TYPE) return DEGREE_TYPE; 

procadure PUT(DATA : in NAV_DATA_TYPE); 
end NAV DATA; 
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with TEXT_IO, CALENDAR; 
use TEXT_IO, CALENDAR; 
package body NAV_DATA is 

package INTEGER_INOUT is new INTEGER_IO(INTEGER); 
package FLOAT_INOUT is new FLOAT_I0(FLOAT); 
use INTEGER_INOUT, FLOAT_INOUT; 

— 648,000,000 = 180 DEGREES (longitude) 

— range of latitude is +/- 324,000,000 {+/- 90 degrees) 
function NAV_CONVERSION(VAR : LONG_INTEGER; 

DATA : DEGREE_TYPE) return DEGREE_TYPE is 
RESULT : DEGREE_TYPE; 

DEG, MIN, REMAINDER : LONG_INTEGER; 
begin 

— integer division to extract degree component 
DEG ;= VAR/360000; 

RESULT.DEGREES := INTEGER(DEG); 

— integer division to extract minute component from 

— remainder 

MIN := (VAR - DEG * 360000)/6000; 

RESULT.MINUTES := INTEGER(MIN); 

REMAINDER := VAR - ((DEG * 360000) + (MIN * 6000)); 

— float division to extract seconds component 
RESULT.SECONDS ;= FLOAT(REMAINDER)/100.0; 
return RESULT; 

end NAV_CONVERSION; 

procedure PUT(DATA : in NAV_DATA_TYPE) is 
SECS : DURATION; 
begin 

if DATA.LATITUDE.DEGREES >= 0 then 
PUT('N'); 
else 

PUT('S' ) ; 
end if; 

PUT(DATA.LATITUDE.DEGREES, WIDTH => 4) ; 

PUT(" DEG "); 

PUT(DATA.LATITUDE.MINUTES, WIDTH => 3); 

PUT(" MIN "); 

PUT(DATA.LATITUDE.SECONDS, FORE => 3, AFT => 2, EXP => 0); 
PUT_LINE(" SEC"); 

if DATA.LONGITUDE.DEGREES >= 0 then 
PUT('E'); 
else 

PUT('W'); 
end if; 

PUT(DATA.LONGITUDE.DEGREES, WIDTH => 4); 

PUT(" DEG "); 

PUT(DATA.LONGITUDE.MINUTES, WIDTH => 3); 

PUT(" MIN "); 

PUT(DATA.LONGITUDE.SECONDS, FORE => 3, AFT => 2, EXP => 0); 
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PUT_LINE(" SEC "); 

PUT("DEPTH ; "); 

PUT(DATA.DEPTH, FORE => 3, AFT => 2, EXP => 0); 
NEW_LINE; 

PUTC'PDOP : "); 

PUT(DATA.PDOP, WIDTH => 5); 

NEW_LINE; 

PUT("TIME ; "); 

SECS ;= SECONDS(DATA.FIX_TIME); 

PUT(FLOAT(SECS), FORE => 6, AFT 2, EXP => 0); 
NEW_LINE; 
end PUT; 

end NAV DATA; 
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File Name ; DR.A 

Author : Lcdr C. D. Stevens 

Date : 03 December 1992 

Comments : DR provides the basic navigation functions 
Delta_Update calculates the latitude and 
longitude change 

based on the heading, climb angle and depth 
change since 

last delta_update and maintains a cumulative 
vector 


with NAV_DATA, DELTA_POSIT; 
use NAV_DATA, DELTA_POSIT; 
package DR is 

procedure DELTA_UPDATE(PITCH_ANGLE : in FLOAT; 

DEPTH_CRANGE : in FLOAT; 

HEADING : in FLOAT; 

DELTA_POS : in out DELTA_TYPE); 

end DR; 
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with NAV_DATA, DELTA_POSIT, MATH_LIB, TEXT_IO; 
use NAV_DATA, DELTA_POSIT, MATH_LIB, TEXT_IO; 
package body DR is 


— not yet operational as a post proccessor 

— can be linked with operational SANS for real-time processing 

— of DR_Navigation data 

procedure DELTA_UPDATE(PITCH_ANGLE : in FLOAT; 

DEPTH_CHANGE : in FLOAT; 

HEADING : in FLOAT; 

DELTA_POS : in out DELTA_TyPE) is 

TWO_PI ; FLOAT := 6.2832; 

DELTA_LATIT, DELTA_LONGIT : FLOAT; 

ADJACENT, DISTANCE, RADIANS : FLOAT; 
begin 

— Calculate the distance travelled by examining the pitch 
angle 

— and depth change to calculate the horizontal component 

ADJACENT ;= SIN(PITCH_ANGLE)/COS(PITCH_ANGLE); —Tan not 

found 

DISTANCE := DEPTH_CRANGE/ADJACENT; 

— Determine the latitude and longitude components of the 
distance 

RADIANS := HEADING/TWO_PI; 

DELTA_LATIT ;= DISTANCE/COS(RADIANS); 

DELTA_LONGIT := DISTANCE/SIN(RADIANS); 

— update the cumulative vector with the respective 
components 

— of latitude and longitude change 

DELTA_POS.DELTA_LAT ;= DELTA_POS.DELTA_LAT + DELTA_LATIT; 
DELTA_POS.DELTA_LONG := DELTA_POS.DELTA_LONG + DELTA_LONGIT; 
end DELTA_UPDATE; 

end DR; 
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APPENDIX C 


INTERRUPT ROUTINE MAJOR OPERATIONS 

The development of the interrupt-driven routine for tracking gyro rotation was 
outlined in Section IV.B.2.f.(3). This appendix provides specific details outlining the 
implementation’s four basic procedures. 

A. INITIALIZE THE INTERRUPT ROUTINE 

At the execution of the main procedure, host machine’s interrupt vector table 
must be adjusted. This permits the Sapphire interrupt input channel to trigger the 
Gyro’s service routine. 

1. The initialization routine, IN1T_D!G1TAL_C0UNTER disables interrupts and 
saves the current value of registers to be used during initialization. 

2. Interrupt enable is programmed in the Sapphire board through bit 3 
(hexadecimal value 8) of control register 1 (base offset + 2). Interrupt enable must be 
reprogrammed after each interrupt by the interrupt service routine. The value of the 
pitch count is inititalized to 0. 

3. The interrupt vector table is set to respond to hardware interrupt level 7 (IRQ7) 
by transferring control to the interrupt service routine PITCH_CALC. The interrupt 
number and effective address to which control must pass is added to the current vector 
table. 
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4. The current hardware level 7 interrupt vector is saved to be restored after 
termination of SANS. The interrupt level to be replaced (OF hexadecimal corresponds 
to IRQ?) is loaded into the lower half of the AX register (AL) and the function 
number (35 hexadecimal for retrieve current vector) is loaded into the upper half of 
the AX register (AH). AX contains the parameters for Disk Operating System (DOS) 
function call INT 21. The result of the call is the current code segment address (CS) 
returned to the ES register and program counter (IP) returned to the BX register 
(ES:BX). These results are stored in the data segment for later restoration. (Ref. 20] 

5. After the current vector for LPTl has been saved, the new vector is loaded into 
the interrupt vector table. This vector enables the interrupt service routine to be 
acces.sed at each interrupt. The offset operator is used to determine the offset address 
of the service routine PITCH_CALC. This address is loaded as the new address for 
the service routine in the interrupt vector table. To program the vector, the offset 
value is loaded in the DX register and the code segment address (CS register) is 
loaded in the DS register as parameters for DOS function call INT 21. Interrupt level 
(1RQ7) is loaded in AL as before, and DOS function number 25 hexadecimal is loaded 
in AH as additional parameters for INT 21. The result is a new service address for 
IR07 of DS;DX. (Ref. 20] 

6. For IBM compatible architecture, the interrupt mask must be set in the 8259 
programmable interrupt mask. The current interrupt mask is read from I/O port 21 
hexadecimal. The value read from I/O port 21 is AND’ed with 7F hexadecimal (0111 
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1111 binary), to reset IRQ7 (bit 7). This operation and is performed on the current 
value and 7F hexadecimal to preserve all current interrupLs while enabling the new 
interrupt. The result is written to port 21 hexadecimal. 

7. The contents of the registers are then restored, interrupts re-enabled and control 
restored to the address in the base pointer. 

B. IMPLEMENT THE SERVICE ROUTINE 

1. After the interrupt vector table has been set, interrupts are handled by the 
interrupt service routine. The current stale of both inner gimbals input signals are 
evaluated at each interrupt by reading the contents of the status register from Sapphire 
base offset + 2. 

2. The values of bits 5 and 6 are extracted by operation and with 30 hexadecimal 
(0011 0000 binary). This makes all bits zero except bits 5 and 6 which retain their 
value. The result indicates the current state. 

3. This state is compared with the previous slate recalled from memory to 
determine if the stale transition is valid as described by Figure 4.4. The cumulative 
rotation since initialization is incremenied/decremented as appropriate. 

4. The interrupt service routine resets interrupt enable in the Sapphire board 
through bit 3 of control register 1 for subsequent interrupts. 

C. CURRENT^VALUE 

The main procedure must be able to access the result of the interrupt service 
routine’s tracking of the gyro rotation. Ada function READ_PITCH interfaces with 
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the assembly language procedure READ_PITCH which loads the current value of the 
pulse count from the data segment into register CX. The contents of CX is the 
function return value. 

Whenever the gyro’s CURRENT_VALUE is required by the main procedure, the 
pulse count (cumulative rotation since initialization) is determined by a function call to 
READ_PITCH. The difference since the last update is applied as gyro rotation to 
determine the new pitch angle. 

D. RESTORE INTERRUPTS 

Before program termination, the interrupt vector table Is restored to its initial 
condition through procedure RESTORE_!NTERRUPTS. This requires restoring the 
interrupt mask and vector stored in the data segment at initialization to their initial 
configuration. 

1. Interrupts are disabled, register contents are saved and the data segment is made 
visible. 

2. The original interrupt mask is loaded from memory to the AX register. This 
register’s contents are written to port 21 to reconfigure the 8259. 

3. The original interrupt vector table is restored by loading the original interrupt 
vector address for IRQ7 from memory into the DX:DX register pair. IRQ7, which is 
OF hexadecimal, is loaded in AL as before and DOS function number 25 hexadecimal 
is loaded in AH as AX register parameters for DOS function call INT 21. The result 
of the DOS operation is restoration of the original service address for LPTl. [Ref. 20] 
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APPENDIX D 

STATE TRANSITION TRACKING ALGORITHM VERIFICATION 

CASE 1 : clockwise rotation (the counter is incrementing). 

The result should be 4 units of rotation @ 0.4 degrees/unii. 

IG-A IG-B PITCH COUNT STATE TRANSITION CASE 


0 

1 

0 

1 

0 

1 

0 

1 


0 

1 

1 

2 

2 

3 

3 

4 


GIMBALS A 


1 

2 

1 

2 

1 

2 

1 

2 


1 

2 

1 

2 

1 

2 

1 


GIMBALS B 

INTERRUPT 
INPUT 

STATE 




_iUI_lUI_lU. 


L 


FT 


1 2 


1 a 


l 2 


1 2 


Figure D.l : Case \ State Transitions 
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CASE 3 : counter-clockwise rotation (the counter is decrementing). 
The result should be -4 units from initial value. 


IG-A IG-B PITCH COUNT 


1 0 4 

1 1 3 

1 0 3 

1 1 2 

1 0 2 

1 1 1 

1 u 1 

1 1 0 


STATE TRANSITION CASE 
3 

2 3 

3 2 

2 3 

3 2 

2 3 

3 2 

2 3 


GIMBALS A 


GIMBALS B 


INTERRUPT 

INPUT 


STATE 32 32 32 32 



Figure D.2 : Case 3 State Transitions 
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CASE 1 to CASE 3 : reversal in rotation, clockwise to counter-clockwise. 


The result should be 0, increment 2 then decrement 2. 


IG-A 

. IG-B 

PITCH COUNT 

STATE 

TRANSITION 

0 

1 

0 

1 

- 

1 

1 

1 

2 

1 

0 

1 

1 

1 

2 

1 

1 

2 

2 

1 

1 

0 

2 

3 

2 

1 

1 

1 

2 

3 

1 

0 

1 

3 

2 

1 

1 

0 

2 

3 



INTERRUPT 

INPUT 


STATE 12 12 32 32 


Figure D.3 : Case 1 to Case 3 Rotation Reversal 


I 

I 
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CASE 3 to CASE 1 : Reversal in rotation, counter-clockwise to clockwise. 
The result should be 0, decrement 2 then increment 2. 


IG-A IG-B 

PITCH COUNT 

STATE 

TRANSITION CASE 

1 

0 

0 

3 

- 

1 

1 

-1 

2 

3 

1 

0 

-1 

3 

2 

1 

1 

-2 

2 

3 

0 

1 

-2 

1 

2 

1 

1 

-1 

2 

1 

0 

1 

-1 

1 

2 

1 

1 

0 

2 

1 


GIMBALS A 


GIMBALS B 

INTERRUPT 
INPUT 

STATE 




j— 

— 

fM! 

1 r 




IL 


3 3 


3 3 


1 3 


1 3 


Figure D.4 : Case 3 to Case 1 Rotation Reversal 
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CASE 0 : Gyro is stationary with noise in IG-A. 

The result should be 0 (ignore noise). 

IG-AIG-B PITCH COUNT STATE TRANSITION CASE 
1 0 0 3 - 

1 0 0 3 0 

1 0 0 3 0 

1 0 0 3 0 

1 0 0 3 0 

1 0 0 3 0 

1 0 0 3 0 

1 0 0 3 0 


GIMBALS A 


GIMBALS B 


INTERRUPT 
INPUT 

STATE 3 3 3 3 



Figure D.5 : Noise in IG-A 
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CASE 0 : Gyro is stationary with noise in IG-B. 

The result should be 0 (ignore noise). 

IG-A IG-B 
0 1 
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Figure D.6 : Noise in IG-B 


1.33 







CASE 0 : Gyro is stationary with noise in both channels. 


The result should be 0 (ignore noise). 
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Figure D.7 : Noise in Both Channels 
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CASE 4 : Gyro is stationary with noise in both channels. 
The result should be 0 (ignore noise). 
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Figure D.8 : Noise in Both Input Channels 
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APPENDIX E 


A. GPS MESSAGE TRANSLATION TEST CASES 

The following is a typical 68 byte binary message with each byte 
represented by its equivalent integer value : 

64 64 66 97 

1 2« 7 201 

19 39 6 0 14 12 23 

7 218 54 110 

229 217 60 97 

0 0 3 84 

0 0 14 231 

0 139 11 235 

0 73 0 

4 4 

15 8 96 128 

25 8 112 136 

0 0 0 0 

29 8 107 136 

14 8 112 136 

0 0 0 0 

32 
143 

13 10 

TEST CASE I 

Header: 

@ @ B a (This header corresponds to a 

64 64 66 97 position format message and is 

processed after storage) 

Month Day Year (7 * 256 + 201 =1993) 

1 26 7 201 => (January 26, 1993) 

Hours/Minutes/Seconds and fractional seconds 
19 39 6 0 14 12 23 

=> 19:39:06.000920599 

Latitude (in milliseconds) 

7 218 54 110 

(7 * 2exp24) + (218 * 2expl6) + (54 * 2exp8) + 110 

=> 131,741,294 

Longitude (in milliseconds) 

229 217 60 97 => 3,856,216,233 > 2exp31 

(3,856,216,233 - 2exp32) => -438,748,063 (two's complement) 


Header 

Date 

Time 

Latitude 

Longitude 

Velocity 

Heading 

Height 

PDOP/Type 

Satellites/Tracked 
Channel 1 
Channel 2 
Channel 3 
Channel 4 
Channel 5 
Channel 6 
Receiver Status 
Checksum 
End Delimiters 
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Velocity 
0 0 3 84 

PDOP (decimal value) 

0 73 

(0 * 2exp8) + 73 = 73 

Satellite status information 
4 (visible) 4 (tracked) 


ID 

mode 

strength 

flags 

15 

8 

96 

128 

25 

8 

112 

136 

0 

0 

0 

0 

29 

8 

107 

136 

14 

8 

112 

136 

0 

0 

0 

0 

32 

(receiver status) 

143 (checksum) 

13 

10 

<CR><LF> end 

of message delimiters 


OUTPUT: 

North 36.594803 degrees (131,741,294 milliseconds) 

West 121.87446 degrees (-438,748,063 milliseconds) 

PDOP : 7.3 (in decimal range 0.0 to 99.9 for Motorola) 

TEST CASE II 

Header corresponds to a satellite range format message. The 
message is not processed after writing to non-volatile memory. 

@ § B g 

64 64 66 103 

Time (in seconds) Fractional seconds (in nanoseconds) 

2 12 66 1 15 90 225 


SVID Mode GPS Time Carrier/Code Phase 

(Seconds/Fractional Seconds) 


18 

8 

8 

12 

92 

66 

225 

8 

212 

82 

12 

4 

8 

12 

9 

11 

7 

13 

8 

8 

12 

92 

66 

225 

8 

210 

88 

11 

5 

6 

66 

8 

22 

7 

8 

8 

8 

12 

92 

66 

225 

8 

224 

99 

13 

6 

8 

88 

9 

11 

8 

9 

8 

8 

12 

92 

66 

225 

8 

214 

103 

12 

4 

5 

99 

8 

33 

9 

24 

0 

7 

16 

88 

55 

107 

0 

112 

122 

55 

5 

8 

88 

9 

22 

6 

16 

8 

8 

12 

92 

66 

225 

8 

214 

44 

66 

7 

8 

55 

8 

11 

6 


73 Checksum (Exclusive OR of all bits after @@) 

13 10 <CR><LF> (Carriage Return/Line Feed) End Delimiter 
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Heading Height 

0 0 14 231 0 139 11 235 

PDOP type 
0 





TEST CASE III 


Only the latitude/longitude conversions are addressed henceforth. 
Input; 

Latitude (bytes 15-18) 

255 218 54 125 (-2,476,329 milliseconds in two's 

complement) 

Longitude (bytes 19-22) 

255 217 60 72 

(-2,440,472 milliseconds in two's complement) 

Output: 

South -0.687869 degrees 

West -0.677909 degrees 

TEST CASE IV 

Input: 

Latitude 

0003 (000,000,003 milliseconds) 

Longitude 

0004 (000,000,004 milliseconds) 

Output; 

North 0.0000000 degrees 

East 0.0000000 degrees 
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APPENDIX F 


MOTOROLA ACQUISITION TIME 

90 SECONDS OFF 



Figure F.l : Motorola Acquisition Time After 90 Seconds OfT 
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Figure F.2 : Motorola First Fix Accuracy After 90 Seconds OfT 
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LATITUDE 


MOTOROLA ACQUISITION TIME 

to MINUTES OFF 



Figure F.3 : Motorola Acquisition Time After 10 Minutes Off 
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Figure F.4 : Motorola First Fix Accuracy After 10 Minutes Off 
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MOTOROLA ACQUISITION TIME 

30 MINUTES OFF 



Figure F.5 : Motorola Acquisition Time After 30 Minutes Off 


FIRST FIX ACCURACY (in meters) 

30 MINUTES OFF 
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Figure F.6 : Motorola First Fix Accuracy After 30 Minutes Off 
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MOTOROLA ACQUISITION TIME 

OME HOUR OFF 



22 STAHDARD DEVIATION . 2.70 SECONDS 


Figure F.7 : Motorola Acquisition Time After One Hour Off 


FIRST FIX ACCURACY (in meters) 

ONE HOUR OFF 



Figure F.8 : Motorola First Fix Accuracy After One Hour Off 
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MOTOROLA ACQUISITION TIME 

3 HOURS OFF 



Figure F.9 : Motorola Acquisitimi Time After 3 Hours Off 
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Figure F.IO : Motorola First Fix Accuracy After Three Hours Off 
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MOTOROLA ACQUISITION TIME 

SIX HOURS OFF 



Figure F.ll : Motorola Acquisition Time After 6 Hours Off 


FIRST FIX ACCURACY (in meters) 

SIX HOURS OFF 



Figure F.12 : Motorola First Fix Accuracy After 6 Hours Off 
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